Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.
It just occurred to me that I can add a job scheduler entry (ADDJOBSCDE) and specify a user profile under which the scheduled job will run.
What if specify QSECOFR or another "powerful" user profile as the user profile?
What if the program that will be run is a CL program that changes "my" user profile to *ALLOBJ?
I may have to try this at home.
Wow, that's unfortunate. It actually did exactly what I expected... it changed my authority. So there you have it. Put a command on the job scheduler as USRPRF(QSECOFR) and it'll run it as QSECOFR.
There must be something else blocking this kind of thing... right?
When I tried to add a job schedule entry running under QSECOFR without having authority to that user profile, it gave me a Not authorized to user profile QSECOFR message and wouldn't let me add the entry.
Good to know. I'm not supposed to be able to change my own SPCAUT settings, however. But I was able to using the above technique. I must have authority to QSECOFR, but I don't know what "authority to QSECOFR" means, specifically.
Yes, the job scheduler allows this, a Q user profile, unlike SBMJOB which does not allow them.
Chris Ringer
It depends on how security is setup on your system. On one system I have no authority to other profiles so I cannot do it. On another I was able to schedule a job as another user and grant myself *ALLOBJ authority.
See the help for both ADDJOBSCDE and SBMJOB. For USER keyword on ADDJOBSCDE, you need *USE to the user profile that the job is to run under.
Dale, yes, but I think this may be design flaw... Fish and I shouldn't have been able to do anything more than we normally would using a compiled CL program that we write/create.
The flaw is that you were granted *USE to QSECOFR (or other powerful user). Shame on your security officer. If you're in a public company, the auditors should be checking this.
Not public.
I doubt most SOX auditors would know anything about this. There are plenty of "back doors" built right into the system. For example, we are not suppose to have access to a command line on our production machine. But, we are allowed to have query and SQL due to most of our database files being secured. When I need a command line I go into my STRSQL option and type 'CALL QCMD'.
Isn't there also protections that you cannot compile a program containing commands that you are not authorized to. This has prevented me from creating utility programs in the past, because SECOFR had the system locked down so tightly. But then while this can prevent you from creating a CL, there's no block on compiling a program with commands that are executed through QCMDEXC.
True - if you are not authorized to a command, you cannot compile a CL program containing that command. But with QCMDEXC you're not actually referencing the command at all - the command is just content in a *CHAR variable. So, with QCMDEXC, the authority to the command that's in the QCMDEXC parameter won't be checked until you try to run it.
Here's another little quirk - You don't need to be authorized to the *CMD's command processing program, PGM(). Ran this past IBM at one point. Turns out when you try to run a command, the system checks object authority on the *CMD, but does not check any authority on the PGM() behind the command. It's only that first *PGM, though. It doesn't extend to objects referenced from the program, such as files, calls to other programs, etc. Not sure about PGM(*REXX), but I'd hazard a guess that it will ignore authority on the REXX source *FILE.
Dale, so that could mean that some shops where copying the original IBM i CL Commands from QSYS to a user library and changing their defaults, could also provide a backdoor to that function. For example if you lockdown PWRxxxSYS and there's a dup of it, that Dup's authority is all that is tested when that copy is being run?