|
Rob: 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. Tom Liotta midrange-l-request@xxxxxxxxxxxx wrote: > 8. Re: Authorization list api's (rob) > >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@xxxxxxxxxx> > >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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.