|
David, > If I am signed on as QSECOFR, and run a program (ILE CL) that is owned > by a normal user and has USRPRF(*OWNER), what is the programs effective > authority? QSECOFR or the users? Adopted authority is always additive to the authority of the current thread/process. But when it is not needed it is not used. The answer to your question above is: QSECOFR authority plus adopted user authority gives your program QSECOFR authority. Tom Liotta wrote on 02/22/2005 05:07:38 PM: > Now, AFAIK, QSECOFR special authorities cannot be changed > (Svalgaardisms notwithstanding, etc.) and *ALLOBJ short-circuits > user authority checking for an object. Hence, it would seem that the > problem ought to be at a point after the first profile swap has > taken place. I.e., QSECOFR authority should be sufficient, > regardless of USRPRF(*OWNER), to swap to some other profile. This followed my previous line of thinking; but Tom's note caused me to remember the *NOPWDCHK and (new in V5R3) *NOPWDSTS special values for QSYGETPH. Is it possible that the problem is not that the other security officer profile does not have *USE authority to QSECOFR, but instead is that the profile is disabled or its password is expired? It that is the case then you will have to specify *NOPWDCHK or *NOPWDSTS instead of *NOPWD for the password parameter on QSYGETPH. Ed Fishel, edfishel@xxxxxxxxxx
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.