Re-Adopt Authority Utility

June 9, 2010 Patrick Botz

Adopted authority is a great way to avoid giving users direct access to data. However, there are a couple of challenges with changing an existing application to rely on adopted authority. First, adopted authority is not propagated to submitted jobs. Second, adopted authority must be removed whenever a command line is provided for the end user. Third, in a production environment it is difficult to find which programs must adopt authority without breaking production users.

Alternative public authority, as described in my previous tip, addresses the last issue. This tip addresses the first issue.

To describe the tip, I’ll first set up an example. Assume we have a large application, MYAPP. We have changed all the data objects to PUBLIC *EXCLUDE with no private authorities. We changed the programs and data for the application to be owned by user profile MYAPPOWNUP and we changed the initial program (MYAPPPGMS/MYAPPINIT) to adopt MYAPPOWNUP. However, finding all the programs/commands that are submitted by the application is not realistic. Our end user, FRED, is running MYAPP and is four menus deep. He selects an option which, unbeknownst to us, executes the following command:

SMBJOB CMD(MYAPPPGMX PARM(xyz))

MYAPPPGMX must run with MYAPPOWNUP adopted authority to work properly, but since it is submitted, it only runs with FRED’s authority.

Before continuing, let me warn you that describing “how” this works is more complicated than implementing the solution.

You can solve this problem by building two programs:

a small “wrapper” program (READOPTWP)
a SBMJOB command change exit point program (READOPTEP)

I also recommend creating a user profile with *ALLOBJ and *SECADM special authority (READPOTUP) for use with the utility. The profile should be *DISABLED and password should be *NONE. I refer to these programs as the READOPT utility.

READOPTWP is owned by and adopts the application’s owning profile (MYAPPOWNUP). It accepts two parameters: USERID and CMDSTR. PUBLIC authority is *EXCLUDE with no private authorities. READOPTWP swaps to the user profile specified in the USERID parameter and then calls QCMDEXEC with the contents of the CMDSTR parameter.

READOPTEP is just a little more complicated than the READOPTWP program. It determines if MYAPPOWNUP adopted authority is in effect for the job performing the SBMJOB command. If it is, it changes the value of the CMD and USER parameters of the SBMJOB command before returning to the system. All other SBMJOB parameters are left unchanged. If adopted authority is not in effect, it returns to the system without changing the command.

To determine if adopted authority is in effect, READOPTEP retrieves the current job stack. Starting with the most current job, it checks the stack for a specified library and program (MYAPPPGMS/MYAPPINIT in our example).

If found, READOPTEP checks if the SBMJOB USER() parameter is set to something other than the current job user profile. If so, it saves this value. Otherwise, the exit program saves the current user profile of the executing job (saved-usrprf). In either case the USER parameter of the SBMJOB command is changed to USER(READOPTUP).

If MYAPPPGMS/MYAPPINIT is found, READOPTEP also saves the original value of the CMD parameter of the SBMJOB command (orig-cmd-str).

READOPTEP changes the CMD parameter value to CMD( READOPTWP CMDSTR(orig-cmd-str) USERID(saved-usrprf) ). All other parameters to the SBMJOB program remain unchanged.

READOPEP adopts the READOPTUP user profile. MYAPPOWNUP has *USE to READOPTWP and PUBLIC is *EXCLUDE. This solves any authority issues related to job queues, programs, user profiles, and swapping. It also prevents users from calling READOPTEP directly.

Going back to our example above, READOPTEP would change the original SBMJOB command to the following:

SBMJOB
 CMD(READOPTWP CMDSTR(MYAPPPGMX PARM(xyz) USERID(FRED) ) )
 USER(READOPTUP)

MYAPPPGMX runs under user profile FRED, and also runs with adopted authority MYAPPOWNUP. Problem solved.

Describing why the READOPT utility works is much more complicated than building the utility! READOPTEP is a relatively simple exit point program that checks for a specific library/program in the job stack. If found, it changes the CMD and USER parameter values. READOPTWP is even simpler. It swaps to a user profile provided in the USERID input parameter and calls QCMDEXEC with the string provided in the CMDSTR input parameter.

I have a tool I use with my customers that automates the implementation of READOPT. In a setup utility, you specify library/program and the user profile it adopts. It creates a version of the READOPTWP program for you and adds the info to a table. A deployment utility registers READOPTEP program. Only one version of READOPTEP is needed. It reads the entries in the table and looks for them in the job stack. If an entry from the table is found in the job stack, it changes the CMD parameter to the call the appropriate version of READOPTWP.

Patrick Botz is the principal consultant and founder of Botz & Associates Inc. He is also president of Valid Technologies, LLC, a biometric middleware ISV. Pat spent nearly 20 years working at IBM in various security roles including lead IBM i security architect, IBM eServer security team, and the head of IBM Lab Services Security Consulting practice. Check out his Website at www.botzandassociates.com. Send your questions or comments for Patrick to Ted Holt via the IT Jungle Contact page.

Low Risk Authority Changes

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot