News Stay informed about the latest enterprise technology news and product updates.

IFS authority considerations -- Part 2

Important IFS authority considerations you should be aware of.

The user changing the owner or group of an object must have sufficient authority to the object; for example, *ADD data authority to the new owner/group user profile and *DELETE data authority to the old owner/group. These are not the same as the file system data authorities. This can be viewed using the DSPOBJAUT command or the EDTOBJAUT command. This can be an issue on some COPY commands when trying to copy the group.

When changing the owner or group of an object, the new owner cannot be the same as the current group, or the new group cannot be the same as the current owner.

To display or retrieve the current working directory (DSPCURDIR, GETCWD(), and so on), you must have *RX data authority to the whole path including Root. To change your current directory (CD, CHDIR(), and so on), you need only *X authority to the whole path. This means that you can change your working directory to a path that you are unable to retrieve.

To change the group of an object, the user must be a member of the new group. Therefore, if the source object of a CPY has a group and the target directory has no group or a different group, the user performing the CPY must be a member of the group for the source object. If not, the user is not authorized to change the group on the newly created copy and an authority failure occurs.

In UNIX environments, users and groups are separate entities. On the iSeries system, however, they are both the same object type (all a type *USRPRF object). The only difference is that a user profile with a group ID is considered a group profile. However, OS/400 security still recognizes the difference.

For example:

 Object . . . . . . . . . .  :    /rjzeller               
 Owner . . . . . . . . . .  :    RJZELLER               
 Primary Group . . . . :    RJZGRP                 
 Authorization List… :    *NONE  

User authorities are set with *PUBLIC to *EXCLUDE, RJZELLER all authorities (*RWX and all object authorities), and RJZGRP all authorities (*RWX and all object authorities). If RJZGRP were to sign on, RJZGRP would not have any authority to '/rjzeller', even though it appears that it has all authority to the object. The listed authority applies only to the members of the group RJZGRP, not to the user RJZGRP. Additionally, you cannot change the group for a "group profile" to itself; that is, the user RJZGRP cannot make RJZGRP a member of group RJZGRP. If the primary group was changed to *NONE and a private authority was added for user RJZGRP, user RJZGRP would have access to the directory. Members of RJZGRP would also have access, because RJZGRP is acting as an AS/400 (iSeries) group profile, not as a UNIX group. This would seem to indicate there is an advantage to simply assigning a private authority for group profiles rather than assigning a group ID for an object. However, private authorities are often not propagated to objects created in a directory. The group always is, though different data authorities may be assigned. Therefore, assigning a primary group to a directory when it is first created will ensure that all objects created in that directory tree will also have that primary group when they are created.

Note: This information was submitted by Search400 expert Ken Graap. It is an IBM software technical document.

About the author: Kenneth Graap is a senior AS/400e system administrator at Northwest Natural Gas in Portland, Ore. He has extensive experience in all aspects of iSeries systems management. That includes proactive performance tuning, system software upgrades and maintenance, hardware upgrade planning, backup/recovery procedures and security.

Dig Deeper on Integrated File System (IFS)

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.