The integrated file system provides multiple ways to store and view information on the system. The integrated file system is a part of the i5/OS operating system
Note: Object security applies to objects whose addressability can be stored in libraries. For object security in the integrated file system, see “Integrated file system security” on page 83.
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.
The root file system acts as an umbrella, or a foundation, for all other file systems on the System i platform. At a high level, it provides an integrated view of all of the objects on the system. Other file systems that can exist on the system 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 system. Similarly, the QFileSvr.400 file system allows applications to access integrated file system data on a remote System i platform. The QLANSrv file server allows access to files that are stored on the Integrated xSeries® Server or other connected servers in the network.
The integrated file system is designed to follow Portable Operating System Interface for Computer Environments (POSIX) standards as closely as possible.
This leads to interesting behavior where i5/OS authority and POSIX permissions are mixed.
For more information about the integrated file system, see the iSeries Information Center at the following Web address and select the path Files and file
system→ Integrated file system→ Overview of the integrated file system:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp
Public authority to the root directory
The default public authority to the root directory is *RWX, *OBJEXIST,
*OBJALTER, *OBJREF, and *OBJMGT. It is important to adequately protect the objects that are created. When a user creates a directory, the public authority to the directory should not be *RWX (the default). The user should set public authority either to *RX or to *EXCLUDE, depending on the contents of the directory.
When you create new directories in the root (/), QOpenSys, or user-defined file systems, you can choose to perform one of the following actions:
Override the default authority when creating new directories. The default is to inherit authority from the immediate parent directory. If you create a directory in the root directory, by default the public authority is *RWX.
Important: A single object can have multiple path names that lead to it (via a symbolic or hard link). Extra care must be taken to ensure that the objects are secured properly, because restricting directory access in one path may still leave access open via a different directory.
Consider changing the public authority for the root directory to prevent users from creating objects in that directory. Remove *W, *OBJEXIST, *OBJALTER,
*OBJREF, and *OBJMGT authorities. However, you need to evaluate whether this change will cause problems for any of your applications. For example, you might have UNIX-like applications that expect to be able to delete objects from the root directory.
Restricting access to QSYS.LIB file system
Because the root file system is the umbrella file system, the QSYS.LIB file system appears as a subdirectory within the root directory. Therefore, any PC user with access to your system can manipulate objects stored in the libraries (the QSYS.LIB file system) with normal PC commands and actions. For example, a PC user can drag a QSYS.LIB object, such as the library with your critical data files, to the shredder if the user has *OBJEXIST authority to the object.
If you do not want users to access the entire QSYS.LIB file system via a network drive, Universal Naming Convention (UNC) name, network neighborhood, or iSeries Navigator, you can restrict access to an IBM-supplied authorization list called QPWFSERVER. If you change the public authority to the QPWFSERVER authorization list to *EXCLUDE, it prevents all network drives from accessing QSYS.LIB.
When a user’s authority to the QPWFSERVER authorization list is *EXCLUDE, the user cannot enter the QSYS.LIB directory from the root directory structure.
When a user’s authority is *USE, the user can enter the directory. When the user has authority to enter the directory, normal object authority applies for any action the user attempts to perform on an object within the QSYS.LIB file system. The authority to the QPWFSERVER authorization list acts like a door to the entire QSYS.LIB file system. For the user with *EXCLUDE authority, the door is locked.
For the user with *USE authority (or any greater authority), the door is open.
For most situations, users do not need to use a directory interface to access objects in the QSYS.LIB file system. You can set public authority to the
QPWFSERVER authorization list to *EXCLUDE. Remember that authority to the authorization list opens or closes the door to all libraries within the QSYS.LIB file system, including user libraries. If you encounter users who object to this exclusion, you can evaluate their requirements on an individual basis. If appropriate, you can explicitly authorize an individual user to the authorization list. However, you need to ensure that the user has appropriate authority to objects within the QSYS.LIB file system. Otherwise, the user might
unintentionally delete objects or entire libraries.
The default public authority to the QPWFSERVER authorization list is *USE. The QPWFSERVER authorization list does not prevent access to directories in QSYS.LIB via FTP, Open Database Connectivity (ODBC), and other protocols.