RE: Authorization list api's

Rob:

Under those circumstances, the authority for USER1 should be returned as -- 
*EXCLUDE. I.e., it ought to work as you hope it would work.

For 'adopted authority' (actually 'group authority'), I was only reminding that 
a given user might have authority to an *AUTL not through private authority but 
through group authority.

Consider the scenario where USER1 is not on the *AUTL at all but has group 
profile GROUP1 and GROUP1 has *USE authority to the *AUTL. The List Objects a 
User is Authorized to, Owns, or Is Primary Group of (QSYLOBJA) API has this 
caveat: "The list does not include objects the user is authorized to because: 
The user is part of a group that is authorized...". Nevertheless, USER1 does 
have *USE authority available.

I suggested the Check User Authority to an Object (QSYCUSRA) API as a helpful 
way to check whether group authority might exist for USER1 for the target *AUTL 
even if USER1 isn't listed. But come to think of it, QSYCUSRA shouldn't help 
you because you wouldn't get the *AUTL in the list from the first API anyway. 
Hmmm... Seems like that requires a more roundabout method.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   7. RE: Authorization list api's (rob)
>
>I am not sure that it is appropriate.  Adopted authority is not the 
>problem.  Think of this scenario.  Authorization list AUTH1 has *PUBLIC as 
>*USE.  USER1 is some funky user (anonymous ftp or some such animal). USER1 
>is listed on that authorization list as *EXCLUDE.
>
>Isn't the api called "The List Objects a User is Authorized to, Owns, or 
>Is Primary Group of (QSYLOBJA) API"?  If so, if I called that asking for 
>USER1 this user would not be "authorized" to AUTH1 would they?  Or would 
>they, meaning does *EXCLUDE still count as being "authorized" to it?
>
>Rob Berendt
>
>qsrvbas@xxxxxxxxxxxx (Tom Liotta) 
>
>I think Carsten's suggestion is appropriate even for *EXCLUDE users. I.e., 
>as long as your program is compiled USRPRF(*OWNER) and owner has 
>sufficient authority, the info returned for a *AUTL ought to include 
>*EXCLUDE for the source user. I haven't actually tried it running _as_ the 
>excluded user, but a security program such as yours probably shouldn't run 
>that way anyway.
>
>And keep group profiles in mind. Consider the use of the Check User 
>Authority to an Object (QSYCUSRA) API to assist in group authorities; 
>maybe it'll be useful depending on exactly how you write your program and 
>who runs it.
>
>midrange-l-request@xxxxxxxxxxxx wrote:
>
>>I believe that the closest that would come is that I could call it, 
>>passing *AUTL and then call another api to see what security the user had 
>
>>on that particular authorization list.  However if the user was listed as 
>
>>*EXCLUDE than I'd be SOL.  I think I'd be better served (until DCR is 
>>done) by listing all objects of type authorization list and then 
>>processing each to see what security that particular user had.  Again, 
>I'd 
>>probably have to think on that *EXCLUDE on that one also.
>>
>>
>>"Carsten Flensburg" <flensburg> 
>>
>>The List Objects a User is Authorized to, Owns, or Is Primary Group of
>>(QSYLOBJA) API might be worth having a closer look at:
>>http://as400bks.rochester.ibm.com/iseries/v5r2/ic2924/info/apis/qsylobja.htm