Troubleshooting
Problem
This document discusses how authority is set on Integrated File System objects.
Resolving The Problem
This document discusses how authority is set on Integrated File System objects.
Authority Considerations for the IBM OS/400 or IBM i5/OS Integrated File System
You should consider the following:
Authority Considerations for the IBM OS/400 or IBM i5/OS Integrated File System
You should consider the following:
| o | Adopted authority is not supported by the Root ('/'), QOpenSys, and user-defined file systems. | ||||
| o | Many operations require *RX authority to the entire path including the root. When experiencing authority problems, verify the entire path including the root rather than only the object and its immediate parent. | ||||
| o | By default, files created with the CPYTOSTMF or CPYTOIMPF commands have data authorities for *PUBLIC set to *NONE and have no group authority regardless of the authorities on the parent directory. Assign the desired authorities using the "Stream file authority" (STMFAUT) parameter. |
||||
| o | To retrieve authority information about an object, the user must have *OBJMGT object authority to the object. This can affect functions such as COPY which needs to retrieve authority information about the source object so it can set the equivalent authorities on the target object. | ||||
| o | 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. | ||||
| o | 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. | ||||
| o | 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. | ||||
| o | 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. | ||||
| o | In UNIX environments, users and groups are separate entities. On the IBM iSeries family of servers 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 or i5/OS security continues to recognize 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 iSeries family group profile rather than 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. |
||||
| o | Initial object authorities are assigned to a new file or directory based on the authority values of the parent directory. The rules involved with this are as follows: a. The owner for the new object has the same object authorities the owner of the parent directory to the parent directory. b. The primary group for the new object the same object authorities the primary group of the parent directory to the parent directory. c. *PUBLIC has the same object authorities to the new object that it has to the parent directory. These rules apply even when the owner of the parent directory and the newly created object are not the same, and even when the owner of the new object has separate private authority to the parent directory. For example: Object . . . . . . . . . . . . . . : /rjzeller Owner . . . . . . . . . . . : RJZELLER Authorization List. . . . . : *NONE User: Object Auth: Object authorities - *PUBLIC *NONE BOB *ALL User BOB signs on and creates a new object (file/dir) under /rjzeller. BOB is the owner of this new object and adopts the same object authority as the owner of object '/rjzeller'. Because RJZELLER does not have authority to '/rjzeller' (no user authorities are listed for RJZELLER), user BOB also does not have object authority to the object he created under '/rjzeller'. This can be a problem for some PC applications (such as Excel and Word) which create a temporary file when opening a current file for edit. When the user attempts to save the file, the application renames the temporary file to the original file name; however, this requires at least *OBJMGT authority which the owner does not have (example above) and, therefore, the user is unable to save the file. The above is true for object authorities. Data authorities are handled differently. Typically, how these are inherited or determined are based on the interface used to create the new object. From most PC interfaces, the owner/creator gets all data authorities regardless of the parent authority. |
||||
| o | The MOV command requires special considerations: Consider '/DIRA/FILEA' which is owned by user USERA; if USERB copies FILEA to '/DIRB', then '/DIRB/FILEA' is owned by USERB. But, if USERB moves FILEA to DIRB, '/DIRB/FILEA' should still be owned by USERA. In both cases, private and group authorities should be the same on the target as on the source. This is usually fine when the MOV involves linking the object to the new directory and unlinking it from the old one. No authorities are retrieved or changed, and conflicts are limited to the object and the source and target directories. However, when crossing file-system boundaries or doing text conversions (or any operation which does not support a true MOVE) the MOV operation becomes a copy-and-delete operation. In the copy portion, the target object must be created. At this time, the object is owned by the user performing the MOV (USERB). The data is copied. Then the attributes are read from the source, including the authority attributes (which requires *OBJMGT). Then the attributes are set on the target. This includes (in order) changing the private authorities, changing the group, and changing the owner. Because USERB owns the new object, USERB can set the private authorities with no trouble. However, suppose that USERB happened to be the group profile for the source object? The new object is owned by USERB and now it wants to set the group to USERB. The MOV fails. Or, suppose that the group on the source object was GROUPA and the target object was created with an initial group inherited from its parent (GROUPB). USERB requires *ADD data authority to GROUPA and *DELETE data authority to GROUPB (these are the data authorities to the *USRPRF objects). USERB must also be a member of GROUPA. We now want to set the owner. USERB requires *DELETE data authority to his own user profile and *ADD data authority to profile USERA. The new object is set up like the old object. Now we must delete the old object. USERB requires *DELETE data authority to USERA and *OBJEXIST authority to the source object (more than required for a usual MOV). These issues could generate an error message CPFA0B1; however, this does not contain the object name so it may be difficult to immediately determine if it is referring to the source or target object. It could be the source or target object or any of up to four user profiles. The FTP command requires special considerations: Individual authorities set on the parent directory (such as QPGMR and QSYSOPR) will not be propagated to any new objects. Primary group profiles will be propagated, however, so a primary group can be added to the command which includes QPGMR and QSYSOPR. Other options to add individual authorities include:
In OS400 V4R4M0 through V5R2M0, when using the EDTF command to create new files, the authority for the parent directory is inherited. This incorrect behavior was fixed at the V5R3M0 release boundary and is documented in the memo to users. In V5R3M0 and all future releases, when using the EDTF command to create new files, the authority for the new file will be *RW regardless of the parent directory authority. The authority for the parent directory is not inherited. |
Related Information
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Component":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB57","label":"Power"}}]
Historical Number
18314911
Was this topic helpful?
Document Information
Modified date:
16 May 2023
UID
nas8N1019591