Plan integrated file system security

The integrated file system provides you with multiple ways to store and view information on the server.

The integrated file system is a part of the i5/OS™ operating system that supports stream input and output operations. It provides storage management methods that are similar to (and compatible with) personal computer operating systems and UNIX® operating systems. With the integrated file system, all objects on the system can be viewed from the perspective of a hierarchical directory structure. However, in most cases, users view objects in the way that is most common for a particular file system. For example, ″traditional″ objects are in the QSYS.LIB file system. Typically, users view these objects from the perspective of libraries. Users typically view objects in the QDLS file system from the perspective of documents within folders. The root (/), QOpenSys, and user-defined file systems present a structure of hierarchical (nested) directories. As a security administrator, you need to understand the following: The following information provides some general considerations for the security of the integrated file system.

The integrated file system approach to security

The root file system acts as an umbrella (or a foundation) for all other server file systems. At a high level, it provides an integrated view of all of the objects on the system. Other file systems that can exist on servers provide varying approaches to object management and integration, depending on the underlying purpose of each file system. The QOPT (optical) file system, for example, allows applications and servers (including the iSeries™ Access for Windows® file server) to access the CD-ROM drive on the server. Similarly, the QFileSvr.400 file system allows applications to access integrated file system data on remote servers.

The security approach for each file system depends on the data that the file system makes available. The QOPT file system, for example, does not provide object-level security because no technology exists to write authority information to a CD-ROM. For the QFileSvr.400 file system, access control occurs at the remote system (where the files are physically stored and managed). For file systems like QLANSrv, the Integrated xSeries® Server for iSeries provides access control. Despite the differing security models, many file systems support consistent management of access control through the integrated file system commands, such as Change Authority (CHGAUT) and Change Owner (CHGOWN).

Here are some tips related to the nooks and crannies of integrated file system security. The integrated file system is designed to follow POSIX standards as closely as possible. This leads to some interesting behavior where server authority and POSIX permissions are ″blended″:
  1. Do not remove the private authority for a user to a directory owned by that user, even if that user is authorized through the public authority, a group, or authorization list. When working with libraries or folders in the standard server security model, removing the owner’s private authority would reduce the amount of authority information stored for a user profile and would not affect other operations. But, because of the way the POSIX standard defines permission inheritance for directories, the owner of a newly-created directory will have the same object authorities to that directory as the owner of the parent has to the parent, even if the owner of the newly-created directory has other private authorities to the parent.

    That may be difficult to understand, so here is an example: USERA owns directory /DIRA, but USERA’s private authorities have been removed. USERB has private authority to /DIRA. USERB creates directory /DIRA/DIRB. Because USERA has no object authorities to /DIRA, USERB will have no object authorities to /DIRA/DIRB. USERB will be unable to rename or delete /DIRA/DIRB without further action to change USERB’s object authorities. This also comes into play when creating files with the open() API using the O_INHERITMODE flag. If USERB created a file /DIRA/FILEB, USERB would have no object authorities AND no data authorities to it. USERB could not write to the new file.

  2. Adopted authority is not honored by most physical file systems. This includes the root (/), QOpenSys, QDLS, and user-defined file systems.
  3. Any objects are owned by the user profile which created the objects, even if the OWNER field of the user profile is set to *GRPPRF.
  4. Many file system operations require *RX data authority to every component of the path, including the root (/) directory. When experiencing authority problems, make sure to check the user’s authorization to the root itself.
  5. Displaying or retrieving the current working directory (DSPCURDIR, getcwd(), etc.) requires *RX data authority to every component in the path. However, changing the current working directory (CD, chdir(), etc.) only requires *X data authority to every component. Therefore, a user may change the current working directory to a certain path and then be unable to display that path.
  6. The intent of the COPY command is to duplicate an object. The authority settings on the new file will be the same as the original except for the owner. The intent of the CPYTOSTMF command, however, is simply to duplicate data. The authority settings on the new file cannot be controlled by the user. The creator/owner will have *RWX data authority, but the group and public authorities will be *EXCLUDE. The user must use another means (CHGAUT, chmod(), etc.) to assign the desired authorities.
  7. A user must be the owner or have *OBJMGT object authority to an object to retrieve authority information about the object. This pops up in some unexpected places, like COPY, which must retrieve the authority information on the source object to set the equivalent authorities on the target object.
  8. When changing the owner or group of an object, the user must not only have appropriate authority to the object, but also must have *ADD data authority to the new owner/group user profile and *DELETE data authority to the old owner/group profile. These data authorities are not related to the file system data authorities. These data authorities can be displayed using the DSPOBJAUT command and changed using the EDTOBJAUT command. This also pops up unexpectedly on COPY when it tries to set the group ID for a new object.
  9. The MOV command is prone to puzzling authority errors, especially when moving from one physical file system to another, or when performing data conversion. In these cases, the move actually becomes a copy-and-delete operation. Therefore, the MOV command can be affected by all of the same authority considerations as the COPY command (see 7 and 8 above) and the RMVLNK command, in addition to other specific MOV considerations.

When using the integrated file system APIs, you can restrict access to objects as you can when using data management interfaces. Be aware, however, that adopting authorities is not supported. An integrated file system API uses the authority of the user profile under which the job is running.

Each file system may have its own special authority requirements. NFS server jobs are the only exception to this rule. Network File System server requests run under the profile of the user whose user identification (UID) number was received by the NFS server at the time of the request. Authorities on your server are the equivalent of permissions on UNIX® systems. The types of permissions are read and write (for a file or a directory) and execute (for a file) or search (for a directory).

The permissions are indicated by a set of permission bits, which make up the "mode of access" of the file or directory. You can change the permission bits by using the "change mode" functions chmod() or fchmod(). You can also use the umask() function to control which file permission bits are set each time a job creates a file.

Parent topic: Plan resource security