Special Authorities - inherited?

[iseriesnewb]

It is my understanding that all special authorities are separate, meaning that no one authority automatically includes another. Below are some basic questions that I have:

1) If an user has *SECADM special authority, then do they automatically have the *AUDIT special authority?

2) If an user has *SECADM special authority, then do they automatically have any other special authorities? If so, which ones?

3) Are there any special authorities that automatically grant or include any other special authorities? If so, which ones

4) Aren?t all special authorities completely separate?


I realize that some questions appear nearly identical. I am really looking for some yes/no answers or maybe some very concise/short ones. Thanks!

[john.sev99]

Re: Special Authorities - inherited?

It is my understanding that all special authorities are separate, meaning that no one authority automatically includes another. Below are some basic questions that I have:

The security reference manual lists the special authorities and a description of what they give however, yes, your understanding is correct. As such, this answers all your questions.

Note that you may need more than just 1 authority to perform a particular task. For instance, if you have *SECADM authority, that doesn't allow you to change a user profile unless you also have sufficient authority to the profile object. Also, authorities can come from other sources such as group profiles and adopted authority.

It would help us to understand why you are asking this - is there something in particular that has happened to cause you to question this?

[tomliotta]

Re: Special Authorities - inherited?

1) If an user has *SECADM special authority, then do they automatically have the *AUDIT special authority?

No. E.g., *SECADM allows running CHGUSRPRF against an authorized profile, but it's not sufficient for running CHGUSRAUD against the same profile.

2) If an user has *SECADM special authority, then do they automatically have any other special authorities? If so, which ones?

No.

3) Are there any special authorities that automatically grant or include any other special authorities? If so, which ones

Yes and no; very much mostly 'no'. One special authority does not grant any other "special authority". However, there are some intersections in details here and there. It would take some digging to find the few examples. One example involves access to spooled files on output queues. From the Security Reference:

"If the output queue is defined as OPRCTL (*YES), a user with *JOBCTL special authority does not need any additional authority to the output queue. A user with *SPLCTL special authority does not need any additional authority to the output queue."

So, while *SPLCTL gives access to all spooled files on any *OUTQ, a user with *JOBCTL special authority also gains access to spooled files on *OUTQs that are restricted from most users by the OPRCTL (*YES) attribute. Those would normally not be accessible if that user didn't own the spooled file.

4) Aren?t all special authorities completely separate?

In general, special authorities grant capabilities. *SECADM grants the capability to change attributes of *USRPRF objects. However, it does not grant object authority to any *USRPRF objects. The object authorities are separate from any capabilities to perform any actions. Actions do not equal objects. Capabilities granted by one special authority are different from those granted by others.

So, using *SECADM as the example, you still need sufficient object authority to a *USRPRF object in order to take an action against an attribute of that object. Once sufficient object authority is granted, the *SECADM user can run CHGUSRPRF against the profile. And granting object authority to a normal user is not enough for that user to run CHGUSRPRF. This is why a *SECADM user would need either *ALLOBJ or authorities granted for all *USRPRF objects in order to change every profile.

[iseriesnewb]

Re: Special Authorities - inherited?

Great answers and all as expected. I was asking simply because there was debate among some of us. My research revealed exactly what all have answered so far. Others in my shop were under the impression that some special authorities inherited others. For example, if an user had SECADM authority, then they automatically had *AUDIT authority.

Thanks for the responses as it really helped.

[john.sev99]

Re: Special Authorities - inherited?

So, while *SPLCTL gives access to all spooled files on any *OUTQ, a user with *JOBCTL special authority also gains access to spooled files on *OUTQs that are restricted from most users by the OPRCTL (*YES) attribute. Those would normally not be accessible if that user didn't own the spooled file.

Although not special authority related, access to output queues can also be controlled by the AUTCHK (Authority to check) parameter. This can be set to *DTAAUT in which case you can specify which users have access to the queue by assigning them private authorities to the queue.

[tomliotta]

Re: Special Authorities - inherited?

Although not special authority related, access to output queues can also be controlled by the AUTCHK (Authority to check) parameter.

Yeah, it can get involved, eh? I didn't want to get too far from 'special authority'; and since maybe 98+% of *OUTQs are AUTCHK(*OWNER), "normally" seemed good enough. But the detail is correct.