Resolving The Problem

OS/400 V3R1M0 introduced the IFS as well as the ability to access all file systems under the root IFS. Previous to this release, there was only the QSYS.LIB file system which was commonly indirectly secured through the command line instead of object level authorities. The QPWFSERVER authorization list (AUTL) was also introduced at this time to help system administrators secure the QSYS.LIB file system from being accessed by remote clients through System i Access file server, and later NetServer file server or file serving between System i systems. By setting Public authority on the QPWFSERVER AUTL to *EXCLUDE, the users are restricted from accessing QSYS.LIB file system by these methods, unless the user is explicitly listed as an authorized user or has *ALLOBJ special authority.

Another method of securing a System i system is with security exit programs. The QIBM_QPWFS_FILE_SERV exit point is used for System i Access file serving, NetServer file serving, QFileSvr.400 access and QNTC access. Regardless of the programming language being used to write the exit program, there is the potential that the program will need to access the QSYS.LIB file system, most commonly for global locale information. The method to access QSYS.LIB file system is dependent on the runtime of the program language being used and how the runtime references QSYS.LIB file system, either by native I/O or by IFS naming.

A situation may occur when Public authority on the QPWFSERVER AUTL has been set to *EXCLUDE and a security exit program compiled to use adopted authority to include *ALLOBJ special authority still encounters CPFA09C "Not authorized to object. Object is /QSYS.LIB/QLGPCMA.LOCALE" or a similar file. There will also be a matching AF audit journal entry for each occurrence. Although the program should have sufficient authority to use QSYS.LIB with the program owner having *ALLOBJ special authority, the processing of the security check on the QPWFSERVER AUTL does not seem to take the adopted authority into consideration.

This issue occurs when the security exit program was compiled to use an activation group other than *CALLER, like *NEW, default or specifically named. You may use DSPPGM to verify what activation group the program is using. If the activation group is other than *CALLER, the program must be recompiled to use *CALLER.