Root, QOpenSys, and user-defined file systems

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, you can assume in the topics that follow that their names 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, iSeries server object authority values.

When a user attempts to access an object in the root file system, OS/400^® enforces all of the object authority values and attributes for the object, whether or not 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 iSeries Access interface. An iSeries server user with a fixed function workstation cannot delete the object either, even if the iSeries server user has *ALLOBJ special authority. Before the object can be deleted, an authorized user must use a PC function to reset the read-only value to off. Similarly, a PC user might not have sufficient OS/400 authority to change the PC-relevant security attributes of an object.

UNIX-type applications that run on iSeries servers 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 (iSeries server 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 iSeries server 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:

• 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 would 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 or not 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.

• Security commands for the root, QOpenSys, and user-defined file systems
  IBM provides a set of commands for working with objects in multiple file systems.

• Public authority to the root directory
  When your system ships, the public authority to the "root" directory is *ALL (all object authorities and all data authorities).

 

Parent topic:

Planning integrated file system security