Object Authority handling under LANSA

Date: Archived
Product/Release: LANSA for the AS/400
Abstract: LANSA uses adopted authority to handle access to OS/400 objects both defined by LANSA and outside of LANSA
Submitted By: LANSA Technical Support

LANSA uses adopted authority to handle access to OS/400 objects defined both by LANSA and outside LANSA. All programs in the LANSA program library are compiled with the USRPRF(*OWNER) option, ensuring that, when they are executed the user temporarily "adopts" the access rights of the owner of the program. All LANSA created I/O modules, processes and functions are compiled with the USRPRF(*USER) option, but, because the LANSA programs call these programs using USRPRF(*OWNER), previously adopted authority (USRPRF(*OWNER)) is retained.

The actual owner of all objects created by LANSA is the system owner profile nominated in the system definition data area DC@A01. This means that, LANSA is used to create a file or program when signed on as QPGMR, the actual owner of the object will be the profile nominated as the LANSA system owner profile (for example QOTHPRDOWN).

This approach, which is used by many AS/400 sites in non-LANSA systems, has been taken because of the following reasons:

  • It vastly simplifies authority maintenance. When a user is not authorized to something, like the OS/400 CHGSYSLIBL command, it is only necessary to grant authority to the system owner and instantly all LANSA users can "adopt" this access while working under the control of LANSA.

    This means that access can be granted to the QOTHPRDOWN (system profile) to a command like CHGSYSLIBL. When signed on as QPGMR the command cannot be directly used, but once inside LANSA, and under the control of LANSA, the command can be used. Access to this command allows 4GL programs to be edited using STRSEU.
  • LANSA defines objects that have no equivalent in OS/400 object level security. For instance the objects field, template, process and function have no direct equivalents in OS/400. This means that LANSA must use a separate security system that is a superset of OS/400 security.
  • LANSA supports a consistent security system across S/38s and AS/400s, whereas CPF and OS/400 have options that vary with each type of machine (e.g. exclusions not supported on System/38s).

Where this approach sometimes causes confusion is in the area of access to data base files. The user defines the file from within LANSA or loads the definition of an OTHER file and then uses external OS/400 security to alter access rights to the file ... only to find that the access changes are ignored while accessing the file within LANSA.

It may even appear to some users that LANSA is somehow doing something really "tricky" and actually allowing the user to "bypass" standard OS/400 or System/38 security.

This is not true. It is simply that the user, in OS/400 security terms, is "adopting" the LANSA system owner's rights to the OS/400 object initially. After this operating system level adoption has been used normal LANSA security checking takes control using the information stored in file DC@F02 to work out what access the user has to the file.

The information stored in this file may be very different to what the OS/400 object level security says, and because the adoption technique allows OS/400 level access, there appears to be some sort of security breach going on.

Of course this is not true. OS/400 security is virtually foolproof and it is the use of the "adoption" technique (provided by OS/400) combined with a mismatch between what the OS/400 level security is and what is stored in file DC@F02 (for use by LANSA) that causes the confusion.

To solve this problem keep OS/400 security and LANSA security information in synchronization. This does not mean that it is necessary to maintain two separate security systems. It can be done by setting byte 486 of DC@A01 to 'Y' to set the external security matching on.

This will allow the LANSA security routines (accessible from the Housekeeping Menu) to alter the external OS/400 object level security at the same time as they are altering LANSA security information in file DC@F02. for more information on this see the support issue regarding "File Security consideration under LANSA".

This means that security can be maintained from just one place ... from within LANSA and ensure that LANSA security (for use within LANSA) and OS/400 security (for use by products like SQL, PC/Support, etc.) are kept in perfect synchronization.

The trick is to ensure that the security changes are made from within LANSA .... not from outside where LANSA will never know that they have occurred.

When using a large number of "OTHER" files this may be a minor inconvenience, because it would be necessary to go into LANSA to change the security on the file.

This may cause many users to immediately ask .... "Why can't standard OS/400 security be used all the time (even as an option) ?"

The answer is simple .... LANSA has a totally integrated security system that is a superset of OS/400 security. Since OS/400 security has no equivalent of a template, a process, a function or a menu entry it cannot support all the facilities that LANSA needs. The only object that LANSA security and OS/400 security have in common is a "file".

When all these things are weighed up it is felt that the "adoption" technique for OS/400 security provides the best and simplest solution for use by all sites in a general purpose product.

Some areas that may be of concern in the uses of adopted authority can be further clarified in the following:

  1. IO modules, when created, will use adopted authority. If this is a security concern, you have the option to use the *IOMNOADOPT key word (in the data area DC@OSVEROP). If this key word appears anywhere in the optional DC@OSVEROP data area the IOM will be created with the USEADPAUT(*NO) option which means that the IOM will not adopt its authority from the LANSA system owner, which is the owner of the IOM object. The IOM will use the user authority of the user executing the LANSA function when accessing the files.
  2. EXEC_OS400/CPF RDML commands used to execute OS/400 commands from within a function have the options USRPRF(*USER), USEADPAUT(*NO) which means that a user who does not have the right level of authority to OS/400 objects will not have access to them. This RDML command will use the user authority of the user executing the LANSA function.

For more information see the support issue regarding "File Security consideration under LANSA".