I recently wrote a tip for IT Jungle that admonishes programmers to stop assuming that the “job user name” is the same user profile under which a job is currently executing. The article provided examples of how to retrieve the current user profile in CL and using system APIs. Well, I received several comments and questions from readers asking why I didn’t mention the RPG ILE Program Status Data Structure (PSDS).
My response will be published as an IT Jungle tip.
As I said in that article, Barbara Morris from IBM provided the definitive answer about whether or not the PSDS could be used to reliably retrieve the current user profile under which a job is executing.
Her answer was essentially “no, it can’t.” She stated that the current user field is only initialized on entry to a procedure. If a procedure changes the current user value in the job, the PSDS will provide the wrong value unless and until that procedure changes it back. In addition, if a procedure calls another procedure or program that changes the current user value and returns the caller, the value of the current user field in the PSDS will be incorrect.
For procedures that don’t call other procedures or programs and don’t mess with changing the current user of the job, Barbara provided an alternative to getting the job’s current user value that is more efficient and less coding than the PSDS. Here is her suggestion.
Rather than use the PSDS, I would write a procedure that returns the value of a variable initialized to *USER. An automatic-storage variable in a procedure is initialized every time the procedure is called.
dcl-proc getCurUser export;
……..dcl-pi *n char(10) end-pi;
……..dcl-s curUser char(10) inz(*user);
……..return curUser;
…..end-proc;
CAUTION: Programmers should understand that this method (as well as the PSDS) will still return the wrong result in a couple of situations.
First, if your procedure performs a profile swap operation, this value will still represent the wrong user value after the profile swap operation and before swapping back to the original user profile.
Second and similar to the first, if your procedure calls the qsyseteuid() API to change just the user profile (not the group(s) also) under which the job is executing, the curUser variable will be wrong after the call to qsyseteuid() and before the call to set it back to the original value.
Finally, if your procedure calls another procedure or program that swaps user profiles (or calls qsyseteuid() ) without resetting the user back to the original user profile before returning, then this value will be wrong also.
In general, I still recommend using the Retrieve Job Information (QUSRJOBI) API as the most reliable way to retrieve the job’s current user profile. It’s guaranteed to return the correct value and you don’t have to worry about your procedure or anything called by your procedure changing the current user profile before you return to your caller.
For more information on the important topic of job authority, read my recent post Access Control: What Most Developers Don’t Know Can Compromise Security. It explains two things:
- Why, when developers rely on users having explicit authority to objects (via default authority or explicitly through their user profile or associated groups), it becomes virtually impossible for administrators to properly protect sensitive objects like the credit card file, and
- Mechanisms you can use to allow users to successfully run, for example, the payroll application without being able to access the payroll file directly through the command line, SQL, FTP, rexec, etc.
