How *PUBLIC Authority Exposes IBM i Data

Understanding *PUBLIC Authority in IBM i Security

IBM i Security in principle requires users to have explicit authority to objects through ownership, group membership or private. However, IBM i also has a unique concept known as *PUBLIC authority, which can lead to unexpected access if not properly understood and managed.

What is *PUBLIC Authority?

In IBM i, *PUBLIC refers to the default authority granted to users who lack specific (private), ownership or group-based permissions. This means that even if a user hasn’t been explicitly granted access to an object, they may still interact with it based on the object’s *PUBLIC authority setting. This behavior can result in access that is unintended, making it essential to understand and control *PUBLIC authority to maintain a secure environment.

Why Object-Level Security Can Be Confusing

Many administrators hesitate to implement object-level security due to confusion when users are “mysteriously” denied access. The IBM i operating system uses a decision flowchart to determine access:

1. Special Authority Check: If the user has *ALLOBJ, access is granted.
2. Private Authority Check: The system checks for specific authority assigned to the user. This will include ownership authorities and authorities on the assigned authorization list if applicable.
3. Group Profile Check: It then checks the user’s group profiles for *ALLOBJ or private authority.
4. Default to *PUBLIC: If none of the above apply, the system uses the object’s *PUBLIC authority.
5. Program Owner authority: If the USER attribute on the program is set to *OWNER adopted authority is used.

How *PUBLIC Authority is Assigned

Every time a new object is created, IBM i assigns *PUBLIC authority based on the AUT parameter in the create command. Options include:

• *EXCLUDE: No access
• *USE: Read-only access
• *CHANGE: Read/write access
• *ALL: Full access
• *LIBCRTAUT: Defer to the library’s authority setting

While *EXCLUDE may seem restrictive, it’s often necessary to enforce tighter control. Best practices recommend a deny-by-default model, where *PUBLIC is granted minimal or no access, and permissions are explicitly assigned to users or groups based on business needs.

Library and System Value Inheritance

When *LIBCRTAUT is used, the object inherits authority from the library’s AUT parameter, which can also be set to defer to the QCRTAUT system value using *SYSVAL. By default, IBM ships QCRTAUT as *CHANGE, which allows users to invoke programs and modify data—posing a security risk if not adjusted.

Recommendation: Keep create commands at *LIBCRTAUT, but configure each library with appropriate authority settings tailored to its contents. This localized control is more secure and audit-friendly than relying on the system-wide QCRTAUT value.

Default Authority on Directories: A Hidden Risk

Unlike traditional objects in the QSYS.LIB file system, directories in the IFS (Integrated File System) behave differently. When a directory is created, the *PUBLIC authority will be derived from the parent directory unless specified using the DTAAUT() and OBJAUT() parameters. This means:

• Any user with access to the system may be able to browse, modify, or delete files within a directory.
• Directory-level permissions are governed by the same object-level flowchart as QSYS.LIB objects.
• Tools like FTP, ODBC, SQL, and DFU can be used to exploit overly permissive directory access.

Best Practices for Directory Security

• Set Root to *PUBLIC DTAAUT(*RX) OBJAUT(*NONE)
  • This sets root to be read only as required by the OS to function. It is shipped as *PUBLIC DTAAUT(*RWX) OBJAUT(*ALL).
• Set *PUBLIC to *EXCLUDE on directories unless explicitly required.
• Use authorization lists to manage access consistently across multiple directories.
• Regularly audit IFS directories for unexpected *PUBLIC access.

• Educate teams on the difference between QSYS.LIB and IFS security models.

   

Moving forward

Granting open *PUBLIC authority is much like handing every employee a key to sensitive filing cabinets. To maintain a secure IBM i environment:

• Adopt a least privilege model.
• Control *PUBLIC authority at the object, library, and system levels.
• Pay special attention to directory permissions, which are often overlooked but highly vulnerable.