Q: When I specify *AUTL for the public authority for an object, I understand that the public authority comes from the *PUBLIC authority entry on the authorization list. Would the public authority from the authorization list be stored in the object header or will the system have to retrieve the authorization list to find the public authority?
A:The *PUBLIC authority for an object-when an authorization list is used-is stored in the object header of the authorization list object, not in the objects that are secured by the authorization list. When you specify *AUTL for an object such as OBJ1, the header of the OBJ1 contains an indication that the public authority comes from the authorization list and the address of the authorization list. The system must reference the authorization list to obtain the *PUBLIC authority. The system must retrieve the *PUBLIC authority from the authorization list object, but this will not result in an authority lookup operation because the *PUBLIC authority is in the header of the authorization list.
The AS/400 does not propagate the *PUBLIC authority from the authorization list into the individual objects. Otherwise each object would need to be changed each time the authorization list *PUBLIC authority is modified (see "Authorization List Internals," MC, November 1993).
Q: I noticed that a change to the printer device in the QSECOFR user profile was not logged in the audit journal. What changes to the user profile are not logged?
A: The audit journal records the changes related to security. You can determine what will be logged by looking at the fields in the audit entry for change profile (CP). Changes to fields other than the fields listed in 1 are not logged.
A: The audit journal records the changes related to security. You can determine what will be logged by looking at the fields in the audit entry for change profile (CP). Changes to fields other than the fields listed in Figure 1 are not logged.
Q: Is it true that unless the system is running migrated S/36 programs there is no need for authority holders?
A: Yes, unless you are running migrated S/36 applications there is no need for authority holders. Authority holders are intended to hold the authority when S/36 database files are deleted and recreated. An authority holder only applies to database files that have a single field typical of most S/36 applications. If you have database files with a single field, authority holders could be used but for practical purposes, the only use of authority holders is for the migration of S/36 programs.
Q: Most of the users on the system have LMTCPB(*YES) and cannot enter commands. However some of the users have LMTCPB(*PARTIAL). What is the difference between a LMTCPB(*PARTIAL) user and a LMTCPB(*NO) user? What commands are restricted from a LMTCPB(*PARTIAL) user?
A: The users that have LMTCPB(*NO) or LMTCPB (*PARTIAL) can run the same commands assuming they are authorized to the individual commands. The only restriction is that a LMTCPB(*PARTIAL) user cannot change the initial program on the sign-on screen. There is no reason to specify LMTCPB(*PARTIAL) unless there is an initial program specified. LMTCPB(*NO) and LMTCPB(*PARTIAL) with no initial program are equivalent. If the LMTCPB (*PARTIAL) user gets a command line, the user can enter commands just like a LMTCPB(*NO) user.
Security Patrol: Security Questions & Answers
Figure 1 Audit Journal Entries for User Profile Changes
Password Changed Password *NONE Password Expired Owner Current Library Priority Limit Initial Menu Special Authority Group Authority Group Profile Initial Program Limited Capabilities Profile Status User Class ADDITIONS FOR V3R1 Supplemental Group Profiles User ID Group Authority Type Group ID System Configuration Special Authority