To manage the authorities to objects in the IFS, you can use either green-screen CL commands or the Navigator for i interface.

Editor's Note: This article is excerpted from chapter 7 of IBM i Security Administration and Compliance: Third Edition, by Carol Woodbury.

The WRKAUT (Work with Authority), CHGAUT (Change Authority), and DSPAUT (Display Authority) commands provide the green-screen interface. When issuing these commands, you identify the object by specifying a pathname rather than using the traditional library_name/object_name *objtype naming convention you’re accustomed to. For example, to work with the authorities to the object proj1.txt in the directory /home/cjw/projects, you’d use this command:

WRKAUT    '/home/cjw/projects/proj1.txt'

If you’re uncomfortable typing a pathname with the CL commands, you can opt to use the WRKLNK (Work with Object Links) command to navigate through the directory structure to the desired directory or object. When you reach the directory or object for which you want to view or change authorities, enter option 9 (Work with Authority) beside it. The WRKAUT command screen will be displayed with the pathname filled in for you.

Your other choice for managing IFS objects is to use Navigator for i. To view the authorities for the root directory using this method, go to My Connections > System_name > File Systems > Integrated File System. Right-click on Root, and choose Permissions. Navigator will display a window equivalent to the WRKAUT command display.

Figure 7.1 shows the WRKAUT command’s display of the default access for the root directory as IBM ships it. Note that *PUBLIC has data authorities *RWX and all object authorities. In “traditional” IBM i security terms, this authority is equivalent to

*PUBLIC(*ALL). Figure 7.2 shows Navigator’s view—this time, with my recommended

*PUBLIC authority setting for root.

You can use the green-screen or Navigator interface to manage the authority of any object, including objects in the QSYS.LIB file system. For example, the screen shown in Figure 7.3 lets you manage authority to all programs in the PROD library. In the following example, all file objects in the PROD library will be set to

*PUBLIC *RX (or *USE).

Figure 7.1: WRKAUT command display: default authority to root (/)

Figure 7.2: Navigator for i permissions window: Recommended access for root (/)

Figure 7.3: Managing authorities to IBM i objects with the CHGAUT command

File Attributes

Objects in the IFS possess some PC-like properties called file attributes that contribute to the way their access is determined and how the objects are managed. File attributes are properties of a file that work in addition to (not as a replacement for) the IBM i authority settings for the file. There are six file attributes:

• Read-only—The file or folder can only be read. It cannot be updated, changed, or deleted when this attribute is
• Hidden—The file or folder is hidden and can’t be worked with unless you know its name.
• System—The file is a system (A folder cannot have this attribute set.)
• Archive—This attribute indicates whether the file or folder should be Some programs use this attribute to determine which objects are backed up.
• Archive (i5/OS attribute)—This attribute has the same meaning as the Archive It cannot be changed.
• Allow save—Determines whether the file will be

To use Navigator for i to set the file attributes for a file in the IFS, navigate through the IFS using Navigator for i to the desired file or folder. Right-click on the object and select Properties. A window similar to the one shown in Figure 7.4 is displayed.

You use the check boxes at the bottom of the window to set the file attributes of the object.

Figure 7.4: Setting file attributes for an IFS file

You can set the file attributes for objects that reside on IBM i by using PC interfaces or by running the CHGATR (Change Attribute) CL command. Note that most people don’t use these attributes. However, if one gets set by accident, it’s good to know they exist. For example, one of my clients couldn’t figure out why they couldn’t update a file—even with a profile that had *ALLOBJ special authority! We determined that the read-only attribute had been set, and that’s what was preventing the file from being updated.

Adopted Authority and the IFS

If you’ve written a traditional application that runs with adopted authority, you know that as long as the owner of the program that’s running either owns or has authority to the object (e.g., a file) being accessed, the person running the program can access the file. However, this scheme doesn’t work for accessing objects in the IFS because the IFS ignores adopted authority.

To access an object in the IFS, the user running the process must have authority to the object. Like accessing an object in a library, the authority can come from *ALLOBJ special authority, a private authority, a primary group authority, or authority to the authorization list securing an object. The method for granting authority that cannot be used is adopted authority. The operating system ignores adopted authority in the IFS. If you don’t want to give users or groups direct authority, your option is to change the process or thread so that it runs as a different user who has sufficient authority to the IFS objects being accessed. To run as a different user, you have several choices: profile swap, profile token, or the UID and GID family of APIs. Chapter 12 discusses these approaches in detail.

Auditing Objects in the IFS

Just as you can audit objects in a library, you can audit objects in the IFS. The challenge comes when you try to read the audit journal entries for these objects. The objects’ names are actually pathnames and can vary quite a bit in length; therefore, they don’t fit in the audit journal’s 10-character object and library entry fields.

You’ll recognize an audit entry for an IFS object by the *N that appears in place of the object name. To determine the object name for such entries, refer to the Absolute Path Name field, which is a field that is 5002 characters long and is at the very end of the audit journal entry.