Root, QOpenSys, and user-defined file systems

These are security considerations for the root, QOpenSys, and user-defined file systems.

How authority works

The root, QOpenSys, and user-defined file systems provide a blending of IBM i, PC, and UNIX** capabilities both for object management and for security. When you use the integrated file system commands from an IBM i session (WRKAUT and CHGAUT), you can set all the normal IBM i object authorities. This includes the *R, *W, and *X authorities that are compatible with Spec 1170 (UNIX-type operating systems).
Note: The root, QOpenSys, and user-defined file systems are functionally equivalent. The QOpenSys file system is case-sensitive. The root file system is not. User-defined file systems can be defined as case-sensitive. Because these file systems have the same security characteristics, in the topics that follow the names root file system, OOpenSys file system, and user-defined file system are used interchangeably.
When you access the root file system as an administrator from a PC session, you can set object attributes that the PC uses to restrict certain types of access:
  • System
  • Hidden
  • Archive
  • Read-only
These PC attributes are in addition to, not replacements for, IBM i object authority values.

When a user attempts to access an object in the root file system, IBM i enforces all of the object authority values and attributes for the object, whether those authorities are visible from the user’s interface. For example, assume that the read-only attribute for an object is set on. A PC user cannot delete the object through a IBM Navigator for i interface. A IBM i user with a fixed function workstation cannot delete the object either, even if the IBM i user has *ALLOBJ special authority. Before the object can be deleted, the read-only attribute value must be set to off by using a PC function, the Change Attributes (CHGATR) command, or the Qp0lSetAttr() -- Set Attributes API. Similarly, a PC user might not have sufficient IBM i authority to change the PC-relevant security attributes of an object.

UNIX-type applications that run on IBM i use UNIX-like application programming interfaces (APIs) to access data in the root file system. With UNIX-like APIs, applications can recognize and maintain the following security information:
  • Object owner
  • Group owner (IBM i primary group authority)
  • Read (files)
  • Write (change contents)
  • Execute (run programs or search directories)
  • S_ISVTX mode bit (restricted rename and unlink attribute)
The system maps these data authorities to existing IBM i object and data authorities:
  • Read (*R) = *OBJOPR and *READ
  • Write (*W) = *OBJOPR, *ADD, *UPD, *DLT
  • Execute (*X) = *OBJOPR and *EXECUTE
The concepts for other object authorities (*OBJMGT, *OBJEXIST, *OBJALTER, and *OBJREF) do not exist in a UNIX-type environment.
However, these object authorities do exist for all of the objects in the root file system. When you create an object using a UNIX-like API, that object inherits these authorities from the parent directory, resulting in the following situations:
  • The new object’s owner has the same object authority as the parent directory’s owner.
  • The new object’s primary group has the same object authority as the parent directory’s primary group.
  • The new object’s public has the same object authority as the parent directory’s public.
The new object’s data authority for owner, primary group, and public are specified on the API with the mode parameter. When all of the object authorities are set on, you get the authority behavior that you expect in a UNIX-type environment. It is best to leave them set on, unless you do not want the POSIX-like behavior.

When you run applications that use UNIX-like APIs, the system enforces all object authorities, whether they are visible to UNIX-type applications. For example, the system will enforce the authority of authorization lists even though the concept of authorization lists does not exist in UNIX-type operating systems.

When you have a mixed-application environment, you need to ensure that you do not make authority changes in one environment that will break your applications in another environment.