Considerations for integrated file systems security

The "root" (/) file system acts as an umbrella or a foundation for all other file systems on the server. At a high level, it provides an integrated view of all of the objects on the system.

Other file systems that can exist on iSeries™ 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 iSeries applications and servers (including the iSeries Access for Windows^® file server) to access the CD-ROM drive on the iSeries server. Similarly, the QFileSvr.400 file system allows applications to access integrated file system data on remote iSeries servers. The QLANSrv file server allows access to files stored on Integrated xSeries^® Server for iSeries or other connected servers in the network.

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 intricacies 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 iSeries server authority and POSIX permissions are used together:

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 iSeries 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. For 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" (/) directory.

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.

Parent topic: