Planning integrated file system security
The integrated file system provides you with multiple ways to store and view information on the server. Careful consideration needs to be given as to who will be allowed to view which files and in what ways.
The integrated file system is a part of the IBM i 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.
- Which file systems are used on your system
- The unique security characteristics of each 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 systems provide varying approaches to object management and integration, depending on the underlying purpose of each file system. The optical (QOPT) file system, for example, allows applications and servers, to access the CD-ROM drive on the system. Similarly, the QFileSvr.400 file system allows applications to access integrated file system data on remote systems.
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. 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).
- 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 will reduce the amount of authority information
stored for a user profile and will 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.
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 cannot write to the new file.
- Adopted authority is not honored by most physical file systems. This includes the root (/), QOpenSys, QDLS, and user-defined file systems.
- 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.
- 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.
- Displaying or retrieving the current working directory (DSPCURDIR, getcwd(), and so on) requires *RX data authority to every component in the path. However, changing the current working directory (CD, chdir(), and so on) 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.
- The intent of the COPY command is to duplicate an object while the intent of the CPYTOSTMF command, however, is just to duplicate the data. The authority settings on the new object can be controlled with either command by using the Authority (AUT) parameter. Each command works slightly different with regard to how the authority is set on the new object. The authority for the new object created by the COPY command may be set based on the authority of the original object, based on the authority for the directory where the new object is created, or a combination of the two. The CPYTOSTMF has similar options on the AUT parameter, or the default option (*DFT) may be selected. With the default option, the creator/owner will be granted *RWX data authorities, but the primary group and *PUBLIC will not get any data authorities and object authorities are based on the object authorities of the directory where the new file is created.
- 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.
- 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.
- 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 the 2 previous comments) 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, 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.