Tweet
I was informed in a posting (different topic) that you could not lock a user with *SECADM out of libraries, files, etc. as all the user would have to do is use CHGUSRPRF to give him/herself access to *ALLOBJ. I have tried this three times now. I cannot duplicate the situation wherein the *SECADM w/out *ALLOBJ is able to modify his/her Special Authorities. Could someone please shed some light on this subject? Thanks in advance, -Bret
-
-
*SECADM without *ALLOBJ
Dear Bret, I believe Chris Ringer was saying that *SECADM could get *ALLOBJ if he had *USE AUT to a *ALLOBJ USRPRF, not necessarily that he could directly extend the SPCAUTs of his own USRPRF. To extend the "your serve" quip, I may be illicitly including the tram lines - but you might try, from the SECADM profile, creating a CLP with USRPRF(*OWNER) that just CALLs QCMD, then CHGOBJOWN to the ALLOBJ profile. That last is the crucial step, and I think having *USE AUT to the *ALLOBJ profile is enough to do it. If so - and I am subject to correction - then, obviously, all Mr. SECADM needs to do is CALL the adopting pgm any time he wants to do what he likes. -
*SECADM without *ALLOBJ
Peter & Bret, It would not be a good idea to give someone *USE authority to a profile that does not need it for a good reason. The default is *PUBLIC *EXCLUDE for a reason. The same goes for any type of special authority, particularly *SECADM, *ALLOBJ, *SECADM, and *AUDIT. With *USE authority to a profile you can manipulate that persons jobs as that person even without *SECADM. I do beleive that it does not extend to a profile with *ALLOBJ, but I haven't tried it out recently enough to say with certainty. David MorrisComment
-
*SECADM without *ALLOBJ
Peter, You are dead on here. If you create a profile with SECADM but not *ALLOBJ authority, the profile would have to adopt authority or be attached to a group profile that had such. In this case, the profile is only able to 'see' itself using the WRKUSRPRF command. It cannot make significant changes to itself without adoption. I am sure there are other ways around this, but for programmers who need to set up profiles from time to time to test with, it is quite useful. The profile can of course see other profiles it created, until the ownership of the profiles is changed (I think) which would then require *ALLOBJ to see them again. The profile it creates are also restricted in state. They do not have and cannot be given special authorities by the SECADM w/out *ALLOBJ. -bret p.s. Sorry for sounding like such an A$$ with the quip. It was unprofessional to say the least.Comment
-
*SECADM without *ALLOBJ
>I was informed in a posting (different topic) that you could not lock a user with *SECADM out of libraries, files, etc. as all the user would have to do is use CHGUSRPRF to give him/herself access to *ALLOBJ.<<
Although a process running with *SECADM can create and change profiles (provided it has *CHANGE authority to the profile it proposes to change), you can never give a special authority to a profile if you do not currently possess that special authority. So a process that does not already have *ALLOBJ cannot bestow it on another profile. Please note that I used the word "process" rather than "profile". A profile with no special authorities can attain special authorities during a process (job) through the use of adopted authority, swapped profiles, or Job Submission. So even though you start out with only *SECADM, you could aquire the other authorities through swapping or adoption. But the central point remains that you can not give out special authorities that you do not possess. jte MC Security EditorComment
-
*SECADM without *ALLOBJ
>I believe Chris Ringer was saying that *SECADM could get *ALLOBJ if he had *USE AUT to a *ALLOBJ USRPRF, not necessarily that he could directly extend the SPCAUTs of his own USRPRF.<<
This is mostly correct, the nit I would pick (and it's a big nit) is that _any_ profile that has *USE authority to an *ALLOBJ profile can become that profile. To be even more accurate, any profile that has *USE authority to any other profile can become that profile. So listen to David when he says to be wary of giving *USE authority to any user profile. If Sally has *USE authority to Jane's profile, Sally can run jobs as Jane. jte MC Security EditorComment
Comment