|
Some Questions on Adopted Authority Programs
Published: November 11, 2009
Hey, Joe:
I compiled your PSSWRDCHG program to change user passwords on the fly and modified it with your follow-up information. When we compiled it the normal way, authorized users couldn't change passwords. We then compiled the program under QSECOFR with the User Profile parameter equal to *OWNER. It worked fine, but doesn't compiling the program this way allow users with command line access to execute the program?
--Mark
Thanks for writing. This sounds like you have two questions about compiling programs with *OWNER adopted authority.
- Does compiling a program with the adopted authority of the QSECOFR user profile allow any user with command line access to run that program?
- How can you tell if a program is compiled with the adopted authority of the program owner?
Regarding the first question, when you set *PUBLIC authority to *EXCLUDE, it prevents anyone who isn't explicitly authorized to run the program from accessing it. With *PUBLIC *EXCLUDE authority, you don't have to worry because even if an unauthorized user has command line access, they won't be able to run the program unless you explicitly change the object's authorization list to provide access for them.
For example, I can use the following Edit Object Authority (EDTOBJAUT) command to view authorities for my version of the PSSWRDCHG program.
EDTOBJAUT OBJ(QGPL/PSSWRDCHG) OBJTYPE(*PGM)
This command would show me a screen that looks something like this.
Edit Object Authority
Object . . . . . . . : PSSWRDCHG Owner . . . . . . . : QSECOFR
Library . . . . . : QGPL Primary group . . . : *NONE
Object type . . . . : *PGM ASP device . . . . . : *SYSBAS
Type changes to current authorities, press Enter.
Object secured by authorization list . . . . . . . . . . . . *NONE
Object
User Group Authority
*PUBLIC *EXCLUDE
JOEH *ALL
USER1 *USE
USER2 *USE
USER3 *USE
If you have *PUBLIC *EXCLUDE listed for your object as shown here, no unauthorized users will be able to run the program. Adding *PUBLIC access to your object authority list designates what action the operating system will take if the requesting user isn't explicitly defined in the rest of the authorization list. In this case, it doesn't matter if the user can get to the command line. They still won't be able to run the program to change passwords if they aren't explicitly authorized to use it. The only thing you have to be careful of is to make sure to add any users to the authorization list that you want to be able to run the program. You can find instructions for adding users to the program's authorization list in my original article.
However, all bets are off if the users you are worried about have *ALLOBJ authority. A user with All Object (*ALLOBJ) authority can get to anything on your partition, even if you've secured it against *PUBLIC access. So if you're being stingy with *ALLOBJ authority, you shouldn't have too much to worry about with this program. But if a user possesses *ALLOBJ authority, they can also probably use the Work with User Profile (WRKUSRPRF) and Change User Profile (CHGUSRPRF) commands to change passwords and bypass running the PSSWRDCHG program altogether.
Regarding the second question, if you're unsure whether your PSSWRDCHG program is compiled using adopted authority (which specifies that i5/OS authority checking allows object access by using both the authority settings of the individual user calling the program as well as the authority settings of the program owner), you can run this Display Program Information (DSPPGM) command to determine what the program's adopted authority setting is.
DSPPGM PGM(QGPL/PSSWRDCHG)
Running this command displays a screen similar to this one.
Display Program Information
Display 1 of 7
Program . . . . . . . : PSSWRDCHG Library . . . . . . . : QGPL
Owner . . . . . . . . : QSECOFR
Program attribute . . : CLP
Detail . . . . . . . . : *BASIC
Program creation information:
Program creation date/time . . . . . . . . . . : 12/03/07 14:16:56
Type of program . . . . . . . . . . . . . . . : ILE
Program entry procedure module . . . . . . . . : PSSWRDCHG
Library . . . . . . . . . . . . . . . . . . : QTEMP
Activation group attribute . . . . . . . . . . : *DFTACTGRP
Shared activation group . . . . . . . . . . . : *NO
User profile . . . . . . . . . . . . . . . . . : *OWNER
Use adopted authority . . . . . . . . . . . . : *YES
Coded character set identifier . . . . . . . . : 65535
Number of modules . . . . . . . . . . . . . . : 1
Check the User Profile parameter on this screen to determine whether the program was compiled to use the adopted authority of the program owner. If the User Profile parameter listed here equals *OWNER, then i5/OS will run the program using both the running user's object authorities plus the program owner's object authorities (i.e., the running user adds, or adopts, the authority of the program owner to his own authority). In this example, the program owner is the QSECOFR user profile. So while the user is running PSSWRDCHG, the user will be able to run all the commands and features of the program using his own and the QSECOFR user's object authorities. This additional authority is only temporary while the user is running the program, and he loses those extra authorities the minute he exits the program.
If the DSPPGM User Profile parameter is equal to *USER, i5/OS will only check the user's authority settings when he goes to run the program. No additional authorities are given to the user when he runs the program. *USER is the default settings for the User Profile parameter for compile commands inside the i5/OS environment.
HTH
--Joe
RELATED STORIES
Changing User Passwords on the Fly
Correcting and Expanding the Program to Change User Passwords on the Fly
 Post this story to del.icio.us
 Post this story to Digg
 Post this story to Slashdot
|
