Security in the IFS

By Rich Loeber

The IBM i OS is rightly known for good built-in security features. For those of us who grew up with it since the early AS/400 days, security requirements for the "native" library file system are pretty easy to understand and administer. When it comes to the Integrated File System (IFS), however, things can work differently. This tip will explore some of the differences and how best to try and deal with them.

If you grew up with the IBM i OS from the early days, you know that the native file system that is based on libraries and objects within those libraries. Security can be implemented at the library level and at the object level and the hierarchy is intuitive. The IFS can be different.

First, remember that the IFS is a global term for a variety of file systems that are available to the IBM i user. In fact, it includes what we refer to as the "native" file system within the QSYS.LIB file system. Other file systems include the "Shared Folder System", also known as the QDLS file system; the "/root' file system, the QOPT file system, the QopenSys file system, the QFileSvr.400 file system and more. These other file systems all employ an organization based on nested directories. Where your files reside will determine your approach to securing them. If you're just using the native file system, this tip is not for you. If you're using any of the other file system (and most IBM i shops today are in this boat), then read on for some things to watch out for.

The exact security set up that you choose will depend on how the files are stored in the file system in question. For example, the QOPT file system (for optical drive operations) has no security at all since there is no way to write security information to the file system, it is read-only.

The IFS file system is designed to follow POSIX (Portable Operating System Interface) standards wherever possible and certain unusual behaviors can happen when this is mixed in with the IBM i OS. Here are some things to watch out for.

When you create a directory, the owner must also appear in the security authorization for the directory. In the native file system, the owner has clear rights to an object, but not so in the IFS. The owner's rights must be defined as a private authority.

For files in the IFS, keep in mind that adopted authority is not honored for most file systems including the root, QDLS and QopenSys file systems. Your application designs may rely on adopted authority for the native file system, but this approach will not work for most other file systems on the IBM i.

Most file systems will require *RX authority to read an IFS file. This will apply to every step in the directory path. If your application needs to read objects in the IFS, make sure that *RX is in place for the entire path structure. Object management rights (the X character) are needed for some functions that you might not normally think of, so it is best to include it.

When making copies of files in the IFS, be careful which command you use. The COPY (or CPY) command will duplicate the file including the file's authority settings. The CPYTOSTMF command, however, is only intended to copy the data in the file. The file created by CPYTOSTMF will be owned by the user that runs the command and the owner's rights from the original file will be dropped. You will have to reset the authority the way you need it once the copy has completed.

For a complete discussion on these along with other things to watch out for, check out the IBM i Knowledge Center in the Security area for your level of the OS.

If you have any questions about this topic, you can reach me at rich at kisco.com, I'll give it my best shot. All email messages will be answered.