The System i operating system (OS) is rightly known for good built-in security features. For those of us who grew up with it, security requirements for the "native" AS/400 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 knew the System i OS in the early days, you know that the native file system 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. But the IFS is different.
First, remember that the IFS is a global term for a variety of file systems that are available to the System 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 systems -- as most System i shops today are -- then read on for some things to watch 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 because it is a read-only file system.
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 System i OS.
Here are some things to watch for when securing the IFS on IBM i:
- 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 System 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 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 publication Tips and tools for securing your iSeries, chapter 11.
If you have a question about this topic, write to me at rich@kisco.com and I'll give it my best shot. All email messages will be answered.
ABOUT THE AUTHOR: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
Did you find this helpful? Write to the editor about your IBM i concerns at Editor@Search400.com.
