The Dangers of Temporarily Changing User Profiles

Hey, Ted:

In "Monitoring for System Request Menu Option 2," you answered a question from Paul, who needed to write a CL program that temporarily changes a user profile. I always worry when I hear someone is going to temporarily change a user profile and then change it back. Lots of things could happen that would cause problems. Paul realized System Request menu option 2 (ENDRQS) could cause problems that would prevent him from returning the user profile to its original state. What neither you nor Paul mentioned, however, is that options 1 and 90 from the System Request menu could also cause problems.

If the user used option 90 to sign off while his profile was changed, Paul's program wouldn't have a chance to change it back. If the user used option 1 to transfer to a second interactive job while his profile was changed, he would be able to make use of whatever changes were made to the user profile. Paul did not say what needed to be changed. If he is changing something like special authorities or the group profile, this could be a problem because the user would have these extra capabilities in the second job.

I would like to propose an alternate solution: that is to use a Presystem Request Program exit program to temporarily block all uses of the System Request menu while the user profile is temporarily changed. If you would like an example of how to do this, see the article I wrote that appeared in the May 2003 issue of iSeries NEWS. The article included several working CL programs.

There is still one more possible exposure. If Paul's CL program does any DDS display file or UIM panel group operations to the 5250 terminal while the user profile is changed, a devious user could prevent Paul's program from finishing by turning off the terminal or ending the emulation session. Since this will probably cause the job to end, Paul's program would not get control. One solution to this problem is to use the Send Scope Message (QMHSNDSM) API to send a scope message that causes a cleanup program to be called when the job ends, or that the program the scope message was sent to ends. Using a scope message also allows cleanup to be done when ENDRQS is used to end a request, but it does not remove the exposure of someone using System Request option 1.

I have one more comment on this article. When sending a request message, it is best to make it look like this:

/* Request msg */

This request message works just the same as the one you used, but it has the advantage that it will not be retrieved to a command line if someone presses F9=Retrieve. The /* and */ characters make the request look like a comment CL command.

--Ed Fishel
IBM

I am grateful to Ed Fishel for pointing out the inadequacies in my response to Paul. I addressed Paul's question rather than the problem.

A Presystem Request Program runs whenever the system request key is pressed. For more information about Presystem Request Program exit programs, go to the iSeries Information Center. To learn more about scope messages, read about the QMHSNDSM API, also in the Information Center.

--Ted Holt

Click here to contact Ted Holt by e-mail.