Securing the Integrated File System (IFS) is an issue that all OS/400 security administrators must deal with because of the way it comes secured--or not secured--from IBM. By default, the IFS comes shipped wide open--the equivalent of *PUBLIC(*ALL). Why would the good folks at IBM Rochester do this, you ask? Because that's the way UNIX applications expect the root (/) directory to be secured. And one of the reasons for implementing the IFS was to allow UNIX applications to port to OS/400.

The IFS consists of several file systems. It always includes the QSYS.LIB file system and may include the NFS file system, the QLANSrv file system that supports the Integrated xSeries Server for iSeries and other Windows 2000 servers on your network, etc. This article concentrates on how to secure the "nonspecific" parts of the IFS--root (/), QOpenSys, and user-defined file systems.

These parts of the IFS use a different authority scheme from the "traditional" QSYS.LIB file system. These parts use a UNIX-based authority scheme. Other file systems use their own authorization method. For example, the QLANSrv file system uses a Windows-based authorization scheme. The UNIX authorities and how they map into OS/400 authorities is in Figure 1.

Note: *OBJOPR authority, an "object authority" in OS/400 terms, is included with the data authorities that make up the implementation of these UNIX authorities on OS/400.

Figure 1: This table identifies how IFS authorities map to OS/400 authorities.


*R (read authority) allows the contents of a directory to be listed or an object (like a stream file) to be read.
*W (write authority) allows a new object, such as a stream file or a subdirectory, to be added to a directory.
*X (execute authority) allows a directory to be traversed.
*RWX equates to the OS/400 authority of *CHANGE.
*RX equates to the OS/400 authority of *USE.

I'll discuss these authorities in more detail later.

IFS Authorities

When managing access to objects in the IFS, you must deal with two sets of authorities--data authorities and object authorities. As you can see in Figure 1, the UNIX authorities of *R, *W, and *X map to data authorities. But even though you might be working with a UNIX application and its objects, the objects are still OS/400 objects "under the covers." So you can't ignore the fact that all OS/400 authorities must be accounted for--thus, the object authorities.

Managing Authorities to IFS Objects

You can manage authorities to IFS object two ways: through green-screen commands or through iSeries Navigator.

To manage through green-screen, use the Work with Authority (WRKAUT), Change Authority (CHGAUT), or Display Authority (DSPAUT) commands. These commands take a path name, not the traditional library_name/object_name *OBJTYPE naming convention that you're used to.

Figure 2 shows the default access for the root (/) directory as it ships. Note that *PUBLIC authority has data authorities *RWX and all object authorities. In "traditional" OS/400 security terms, this is the equivalent of *PUBLIC(*ALL).

Figure 2: Here, the Work with Authority (WRKAUT) command shows the default authority to root (/). (Click images to enlarge.)

If you're uncomfortable typing in the path name, you can navigate through the directory structure using the Work with Link (WRKLNK) command. On the directory or object you wish to change authorities for, take option 9 to Work with Authority. That will take you to the WRKAUT command with the path name filled in for you.

Or you can use iSeries Navigator. Go to My Connections->iSeries_system->File systems-> Integrated File System. Right-click on Root. Choose Permissions. This will bring you to the screen shown in Figure 3.

Figure 3: This iSeries Access Permissions screen shows the default access for root (/).

Managing "Traditional" OS/400 Objects through IFS Authority Commands

You can manage the authority of any object--including objects in the QSYS.LIB file system--by using either the green-screen or iSeries Navigator interfaces. The screen shown in Figure 4 allows you to manage authority to the APPDEVSRC library by using the Change Authority (CHGAUT) command. Figure 4 shows an example identifying an OS/400 object using a path name.

Figure 4: Use the Change Authority (CHGAUT) command to manage authorities to an OS/400 object.

QPWFSERVER Authorization List

You can prevent users from accessing the QSYS.LIB file system through iSeries Access file serving (i.e., via iSeries Navigator), NetServer file serving, and file serving between iSeries systems by removing users' authority to the QPWFSERVER authorization list. IBM ships this authorization list with OS/400. The *PUBLIC authority defaults to *USE. Setting *PUBLIC to *EXCLUDE will prevent users from accessing QSYS.LIB through interfaces like Ops Nav. The best way to think of it is that it will prevent access through directory structure interfaces (Ops Nav presents QSYS.LIB in a directory structure). However, the authority to the authorization list is not checked by interfaces such as FTP, ODBC, or DDM.

Helpful Tools

OS/400 SECTOOLS provides two tools to help you manage authorities to IFS objects. Both Print Public Authority (PRTPUBAUT) and Print Private Authority (PRTPVTAUT) allow you to specify a path name for the object name. When specifying a directory, you also get the option to search the subdirectories and include those objects in the report. Warning: If you run the report for root (/), the printed report for either command can be huge.

There's also a set of free--but unsupported--management tools for IFS from IBM. Some of these tools are quite handy. Tom McBride from IBM Rochester performed a review of the tools. Before downloading and using these tools, I highly recommend that you read this review to get an understanding of the function and purpose of each tool:

• QRYIFSLIB dumps information such as file size, owner, primary group, etc. to an outfile.
• CHGOWNALL runs the CHGOWN command on all files and subdirectories in the specified directory. You can run this tool to make sure all the directory's objects are owned by the correct owner.
• CHGAUTALL runs the CHGAUT command on all files and subdirectories in the specified directory. You can use this tool to make sure the appropriate authorities are set.
• RNMIFSF renames an invalid file or directory name.
• DLTIFSF deletes from the IFS a file containing invalid characters.
• DSPLINK displays the actual location that a symbolic link references.
• CHGCCSID changes the CCSID on one file or all files in a directory.
• ATTRIB allows IFS file attributes to be updated from OS/400 without requiring a network drive or PC connection. For example, this is one way to remove or change the read-only or hidden file attributes for a particular file or files in a specific directory.
• DELTREE deletes all files, directories, and subdirectories from the parent directory down. Obviously, this one needs to be used with caution.

A couple of these tools are very helpful for security administration--especially CHGOWNALL and CHGAUTALL. However, there are side effects to some of the tools, so again, please read the review before using them!

Audit Entries for Objects in the IFS

Just as you can audit objects in OS/400 (or the QSYS.LIB file system), you can audit objects in the IFS. The challenge comes when you try to read the audit journal entries for those objects. The objects' names are actually path names and can be variable in length. You will recognize an audit entry for an IFS object by the *N that appears for the object name. In this case, you will have to refer to the "Absolute Path Name" field, which is at the end of the audit journal entry. If the path name is longer than 5002 bytes, the IFS object name is identified with something called a file ID or FID. This number uniquely identifies the object. To get the path name from the FID, you must use the Get Path Name of Object from Its File ID (Qp0lGetPathFromFileID()) API. Fortunately, not too many path names exceed 5002 bytes!

Gotchas and Helpful Hints

There are some definite "gotchas" associated with the IFS. These gotchas are not necessarily a result of the IFS being poorly architected or implemented; they're a result of the developers in Rochester being forced to follow the way UNIX does things. To an OS/400-bigot, this often constitutes a gotcha! Here are the things you'll want to be aware of:

• It is very easy to over-secure the IFS. Make sure you document the authorization steps you take in case you need to back them out.
• Adopted authority is not honored within the IFS. Therefore, if the user does not have authority to the object, the application has to accommodate it through a version of a profile swap. Next month's "Security Patrol" will discuss authorization methods that work well in the IFS.
• The attribute of a user profile that automatically assigns ownership of newly created objects to the user's group (the OWNER parameter) is not honored. The user--not the group-- always owns a newly created object.
• Displaying the contents of a directory requires *RX data authority to every directory in the object's path. Changing the current directory only requires *R data authority to the directory. Therefore, it is possible for users to change their working directory to a directory for which they cannot display the contents!

Creating New Objects

• In general, a new object inherits the authorities of its directory. (The exception is when you create IFS objects through APIs such as mkdir(), open(), or creat(). With those APIs, you can specify the data authorities for the owner, primary group, and public authorities.) Inherited authorities include the primary group authority, authorization list, and private authorities. The only difference would be the owner if a different user than the directory owner is creating the object.
• Removing the owner's authority to a directory may produce undesirable results when objects are created into that directory. When an object is created into a directory, the owner of the new object is given the same authority as the owner of the directory. Therefore, if a user creates a file into a directory whose owner has had its authority removed, the user will have no authority to the newly created object.
• Given that most IFS APIs allow data authority settings for the owner, primary group, and public to be specified on the call, education may be required for developers to ensure they have specified appropriate values for these parameters. Note: Since most of these APIs are UNIX APIs, they have no concept of object authorities. Therefore, the object authorities are inherited from the parent directory.
• In V5R2, you have a new option for how the primary group is set for a newly created object. Prior to V5R2, the primary group and its authorities were set from the parent directory. Now, you have the option to have the primary group and its authorities set based on the user creating the object.

Copying Objects

• The COPY command creates an exact duplicate of the object, including its authorities (except for the owner, of course). The CPY command does the same thing; actually, the COPY command is an alias of the CPY command, and they can be used interchangeably.
• Since COPY copies authorities, in order to retrieve the authority information about the original object, a user must be the owner or have *OBJMGT to the object being copied.
• The command CPYTOSTMF copies only data, not the stream file's authorities. By default, the owner will have *RWX authority, and the primary group and *PUBLIC authorities will be set to *EXCLUDE. If you want them set differently, you will have to do that (using a command such as CHGAUT) after the stream file has been copied.
• Both the CPY and COPY commands allow you to make the owner of a copied object the same as the owner of the object being copied. Alternatively, you can set it to be the user making the copy. The default is to set the owner to the user making the copy. Depending on how these commands are used, it may be helpful to educate developers on this fact and retain the ownership of the object being copied. Or you could change the command default.

Other authority requirements are listed in iSeries Security Reference, Appendix D under the heading "Integrated File System Commands." This documentation can be very useful in determining what authority is required. (To find the iSeries Security Reference, go to the iSeries Information Center, choose the country, choose the release, and then open the Security tab. iSeries Security Reference is a downloadable .pdf.)

Virus Scanning

While OS/400 itself will not be affected by PC- or UNIX-based viruses and worms, the objects stored in the IFS can be. In addition, the IFS has proven numerous times that it very efficiently and effectively stores and propagates viruses. While there are commercially available virus scanners for Lotus Domino that run natively, there is no commercially available, natively running virus scanner that scans the rest of the IFS. Therefore, you will want to regularly map a drive to root (/), create a one-connection share so the IFS is visible to the network, and run a commercially available virus scanner from your PC against the IFS. You may be able to skip the QSYS.LIB file system, but some IBMers recommend scanning that as well. We recommend that you run the virus scanner at least once a week.

Next Month

Next month's "Security Patrol" will discuss file shares, security schemes for applications using IFS objects. and recommendations for securing the IFS.

Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has over 12 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..