1) Initially assigning an authorization list to an object still requires
exclusive access to an object. They've been around for decades and one
should really know how security works on IBM i before creating your own
tables, etc. Some might push for a DBA. And one who knows IBM i.
2) Some people may actually run more than one application on a single
lpar of IBM i. Actually it's really common. Payroll by package XYZ and
ERP by package ABC. Having one authorization list flagged as the default
for everything would not make sense.
3) As an addendum to item 2 you can assign a default authorization list
to new tables created in a schema. See: CHGLIB LIB(MYLIB) CRTAUT(MYAUTL)
4) To mass blast all objects in a schema it's easy to do a two step
process.
4a) Assign an authorization list to all objects: GRTOBJAUT
OBJ(MYSCHEMA/*ALL) OBJTYPE(*ALL) AUTL(MYAUTL)
4b) Assign *PUBLIC to that authorization list: GRTOBJAUT
OBJ(MYSCHEMA/*ALL) OBJTYPE(*ALL) USER(*PUBLIC) AUT(*AUTL)
4(cont) While I wish it could be done with one statement, this works.
5) One may also use a separate authorization list for your program
libraries versus that for your data schemas. DATACLERK can edit data,
should they be allowed to change programs?
6) Of course, one may want to consider "application only" access for your
data schemas. But, even in that scenario adding Query experts with *use
authority to the authorization list may be desired.
7) One could join OBJECT_STATISTICS to AUTHORIZATION_LIST_INFO to find
objects in a schema not secured by a particular authorization list.
http://ibm.biz/DB2foriServices But I'm rather fond of the mass blasting
as shown in item 4.
Rob Berendt
As an Amazon Associate we earn from qualifying purchases.