Re: object authorities, now have to add QSYSOPR back

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

Ooh ooh ooh!  Mr. Kotter!  Mr. Kotter! (Sorry, late at night flashback.)

Anyway, I've been working with exactly this issue.  I recommend the 
following:

1. Create a "master" authorization list
2. In it, put your authorized users
3. Also in it, put *PUBLIC *EXCLUDE
4. Set the objects to AUTL(autlname) and *PUBLIC *AUTL

Now, every file is at the mercy of the authorization list.  Why is this 
important?  Because you can change authorizations for all 3500 objects 
just by making a single change to the AUTL, and you don't need to lock 
the objects! Booyah!!!!

There are other nuances, such as whether to use a group profile rather 
than individual profiles in the AUTL (I prefer groups), whether you 
should handle exceptions with multiple AUTLs or with adding private 
authorities (depends on the number and variety of exceptions), that sort 
of thing.  But for sure, I find AUTL for everything my new best friend.

:)


On 5/20/2020 4:44 PM, Gerald Magnuson wrote:
> I thought I was almost done... removing *PUBLIC from my production database
> library....
> I have a few objects that need specific authority to allow a very small set
> of users to download, or have those CPYTOIMPF, or CPYTOSTMF commands. some
> objects come in through FTP, and they wind up being owned by user profile
> that runs job...
>
> but I ran into many more cases of our job scheduling tool, running commands
> like "clrpfm", or setting data areas, or CPYF directly, not within a
> program.   and these all run as QSYSOPR, and can't be ran (without levels
> of effort above what I am doing...) as QPGMR.
> so, I am having to grant QSYSOPR *ALL or *CHANGE authority.
>
> since it appears I am going back through the objects(about 3500), should I
> make a *AUTL?  would it just be as easy to mass perform "grtobjaut qsysopr
> *all/*change" ?