Single Thread User Profile Swap
Question: I enjoy your “Security Patrol” column and other articles very much and have implemented several of your techniques and ideas on our AS/400. My latest project involves using your Set Group Profile (SETGRPPRF) command described in your May 1994 MC article, “Dynamic Change of Group Profile.” The program logic of the command processing program (CPP) is shown in Figure 1. My concern regards jobs that may start (either interactive or batch) during the time the user’s group profile is changed to &NEWGRP. I realize that, although the time during which the user’s group profile is &NEWGRP is very short and, therefore, the chances of a user’s job starting during this time are very small, it still could happen. Is there a way to prevent a user’s job from starting until the group profile is changed back to &OLDGRP? Should I be concerned with this problem?
Answer: First, let me congratulate you for an excellent understanding of the potential problems in the timing of jobs. Yes, you should be concerned. When I wrote the code, I did not feel that timing would be a problem since the operations were very fast. That assumption was incorrect as shown from an actual experience. I was working with a client who was making heavy use of the group profile swap function. That client experienced the problem of two jobs changing the group profile for the same user at the same time. This particular installation had a dual processor AS/400, and two batch jobs (each running in a separate processor) started at the same time. Both attempted to perform the profile swap. The timing was such that one job retrieved the incorrect profile name in the &OLDGRP field. (The installation had auditing of the security changes active. The audit journal showed that two profile swaps occurred at the same time—down to the millisecond.) We eliminated the exposure of a simultaneous group profile change by making sure that the profile swap was done single threaded. By allocating an object at the start of the swap and deallocating the object on exit, only one user profile is changed at a time, as shown in the following steps:
1. Create an object (*DTAARA) called SWAP in a library in the library list:
CRTDTAARA DTAARA(QUSRSYS/SWAP) TYPE(*CHAR) +
TEXT(‘Single thread user profile swap’)
2. Modify the SETGRPPRF CPP to include this allocate statement at the beginning:
ALCOBJ OBJ((SWAP *DTAARA *EXCLRD)) WAIT(30)
3. Put this deallocate statement at the end:
DLCOBJ OBJ((SWAP *DTAARA *EXCLRD))
The detail code for the SETGRPPRF CCP with the single-thread logic is shown in Figure 2. This program assumes the user already has a group profile.
Question: I have a question about the printout from the Print User Profile (PRTUSRPRF) command. When there is an X in the No Password column, does it mean that the user doesn’t have a password or that the user is not forced to enter a password?
Answer: User profiles that show an X in the No Password column do not have a password. When a user profile does not have a password, that user profile cannot be used to sign on. Typical reasons for and uses of profiles that have no password are as follows:
• Group profiles should have no password to prevent sign-on as the group profile. Group members should sign on with their individual profiles.
• Object owner profiles should have no password. These could be the user profiles designated to own production data and programs. The IBM profile QSYS is an example of an object owner profile for the IBM objects. Several other IBM-provided profiles that have no passwords, such as QDBSHR and QTMPLPD, fall into this object owner classification.
• IBM ships several model profiles: QUSER, QSYSOPR, QPGMR, QSRV, and QSRVBAS. These profiles are intended to be examples of individual user profiles. I do not recommend that the model profiles be used, and, therefore, they should have no password.
Question: The term exit program is used when talking about securing PC users. What is an exit program? Is this a property of a program? If so, how do I set this property? I cannot find an exit program on the Change Program (CHGPGM) or Create xxx Program (CRTxxxPGM) commands. Could you recommend a book that describes exit programs?
Answer: There is no special property of a program that makes it an exit program. The term exit program is simply a description of the use of a program. In the same way that the term menu program describes a use of a program to display a menu, the term exit program describes a program that is called by the operating system to perform some function before or after a system function. Exit programs are user-written programs that are called by OS/400 before (sometimes after) the system processes a request from a user.
A frequent use of exit programs is to supplement OS/400 security, but there can be other uses. Exit programs often represent installation extensions of OS/400 security in which the exit program allows or rejects some types of user requests.
*NO Password
Exit Programs
Examples of instances when exit programs are used include Client Access/400 (PC Support) file transfer, FTP, and Telnet. The exit program is called when a user initiates a file transfer request; the exit program may allow or reject the request, based on the file name or library being requested for transfer. The exit program may also allow or reject the request, based on the operation being requested; for example, many installations allow PC users’ requests to download (AS/400-to-PC) but prevent their requests to upload (PC-to- AS/400).
Another use of exit programs is to perform additional processing as the result of a user request. An example of this type of exit is the user profile exit. A program can be called when a user profile is created, changed, restored, or deleted. (The user profile delete allows exits before and after deletion.)
The exit programs are specified using either the Change Network Attributes (CHGNETA) command or the Work with Registration Information (WRKREGINF) command. The CHGNETA command has two parameters: DDMACC and PCSACC. They can be used to name the program called before the system processes a request from a PC user or another system.
WRKREGINF provides a way to view the exit points and any exit program names that have been specified. The V4R3 system that I am using has 91 individual exit points defined. The WRKREGINF command allows you to add or remove exit programs. You can also use the Add Exit Program (ADDEXITPGM) and Remove Exit Program (RMVEXITPGM) commands to add or remove exit programs. Although I am not aware of any book that deals exclusively with exit programs, the following is a partial list of the IBM manuals that describe the exits:
• Client Access—AS/400 Client Access Host Servers (SC41-5740)
• FTP and Telnet—OS/400 TCP/IP Configuration and Reference, Appendix I (SC41-5420)
• Security—System API Reference OS/400 Security APIs (SC41-5872) You may also want to review the following past issues of “Security Patrol” that illustrate the use of exit programs:
• Remote Commands—July 1995
• Client Access—October 1995; May 1997
• IFS—September 1997 Question: I am new to the AS/400 and would like to know something about the deletion of group profiles. What happens to the group members when a group profile is deleted? Can you help me?
Answer: Deletion of group and user profiles is controlled by a number of factors and is prevented in the following cases:
1. Group profiles that have members cannot be deleted. To list the members of a group profile, enter the following:
DSPUSRPRF USRPRF(group-profile-name) + TYPE(*GRPMBR)
Then, you need to change the GRPPRF attribute in each member profile before deleting the group profile. Or alternatively, use the Operations Navigator option of Client Access/400 to process the list of users. Operations Navigator will present a list of group members and allow you to point and click to remove the group profile.
Deleting Group Profiles
2. User profiles that own objects cannot be deleted. You must delete any objects owned by the profile or transfer ownership of those objects to another profile. This is simplified because the Delete User Profile (DLTUSRPRF) command has a keyword called Owned object option (OWNOBJOPT) that can be set as follows:
• *NODLT—Do not delete the profile if it owns object.
• *DLT—Delete the user profile and the object it owns. (This action is dangerous—use with caution!)
• *CHGOWN—Change the owner of owned object to another user profile.
3. A user profile cannot be deleted if it is the primary group for any objects. When you use the intermediate assistance level to delete a user profile, you can change or remove the primary group for objects. You can use the Display User Profile (DSPUSRPRF) command with the Object Primary Group (*OBJPGP) option to list any objects for which a profile is the primary group.
RTVUSRPRF RTNUSRPRF(&USER) GRPPRF(&OLDGRP)
CHGUSRPRF USRPRF(&USER) GRPPRF(&NEWGRP)
GRTOBJAUT OBJ(QSYS/&OLDGRP) OBJTYPE(*USRPRF) USER(&USER) +
AUT(*OBJOPR *OBJMGT *READ *DLT *ADD)
CALL PGM(QSYGETPH) PARM(&USER &PASSWORD &HANDLE)
CALL PGM(QWTSETP) PARM(&HANDLE)
CHGUSRPRF USRPRF(&USER) GRPPRF(&OLDGRP)
GRTOBJAUT OBJ(QSYS/&NEWGRP) OBJTYPE(*USRPRF) USER(&USER) +
AUT(*OBJOPR *OBJMGT *READ *DLT *ADD)
Figure 1: Program logic for group profile swap
/********************************************************************/
/* PURPOSE: SETGRPPRFX -- Set group profile */
/* */
/* CRTCLPGM PGM(SETGRPPRFX) USRRF(*OWNER) + */
/* LOG(*NO) RTVSRC(*NO) */
/* */
/* The program must adopt the security officer profile to */
/* get a profile handle without a password */
/* */
/* Set the group profile for a user to the specified */
/* and then swap the user profile to change the */
/* process attributes to use the new user profile. */
/* */
/* The data area SWAP is used to single thread the */
/* changes in the event the change is made in two */
/* jobs at the same time. */
/* */
/* The authority to profiles is granted because the */
/* change group profile revokes access and you need to */
/* repeat the swap of profiles. */
/* */
/********************************************************************/
SWAPGRP: PGM (&NEWGRP)
DCL &NEWGRP *CHAR 10
DCL &USER *CHAR 10
DCL &OLDGRP *CHAR 10
DCL VAR(&HANDLE) TYPE(*CHAR) LEN(12)
MONMSG MSGID(CPF0000) EXEC(GOTO EXIT)
ALLOCATE: ALCOBJ OBJ((SWAP *DTAARA *EXCLRD)) WAIT(30)
RTVUSRPRF RTNUSRPRF(&USER) GRPPRF(&OLDGRP)
CHGUSRPRF USRPRF(&USER) GRPPRF(&NEWGRP)
GRTOBJAUT OBJ(QSYS/&OLDGRP) OBJTYPE(*USRPRF) +
USER(&USER) AUT(*OBJOPR *OBJMGT *READ +
*DLT *ADD)
CALL PGM(QSYGETPH) PARM(&USER *NOPWD &HANDLE)
CHGUSRPRF USRPRF(&USER) GRPPRF(&OLDGRP)
GRTOBJAUT OBJ(QSYS/&NEWGRP) OBJTYPE(*USRPRF) +
USER(&USER) AUT(*OBJOPR *OBJMGT *READ +
*DLT *ADD)
CALL PGM(QWTSETP) PARM(&HANDLE)
EXIT: DLCOBJ OBJ((SWAP *DTAARA *EXCLRD))
MONMSG CPF0000
ENDPGM
Figure 2: Single-thread group profile and swap process
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online