RE: What determine the auth of ifs file created use CPYTOSTMF command?

I found this on IBM.com (required login)... See bullet #3....
http://www-1.ibm.com/support/entdocview.wss?rs=203&context=SW000&dc=DA410&dc=DA450&dc=DA430&dc=DA440&dc=D600&dc=D700&dc=DB510&dc=DB520&dc=D800&dc=D900&dc=DA900&dc=DA800&dc=DB540&dc=DB400&dc=DB560&dc=DB550&dc=D100&dc=DA420&dc=DA460&dc=DB300&dc=DA470&dc=DA480&dc=DB100&dc=DA4A10&dc=DA4A20&dc=DA700&dc=DA4A30&q1=iSeries%20ifs%20authority&uid=nas1e3dc97d7f1aeaf348625685f005c6263&loc=en_US&cs=UTF-8&lang=all&NotUpdateReferer=


Integrated File System Authority Considerations
Technote

Authority Considerations for the IBM OS/400 or IBM i5/OS(tm) Integrated File System

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 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. The CHGAUT command must be used after the CPYTOSTMF or the CPYTOIMPF command fails to assign the desired authorities.
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(tm) 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 following rules involved with this are:

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. Since USERB owns the new object, USERB can set the private authorities with no trouble.

But 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, but 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: 1 Setting authority using the FTP session options (for example, QUOTE RCMD GRTAUT <parameters>).
2 Using an FTP user exit program to grant the authorities required when FTP is used. For an FTP exit program example, refer to Rochester Support Center knowledgebase document 16055109, FTP Exit Program: Server Example . To link to document 16055109 immediately, click here .
The EDTF command requires special considerations:

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.






iSeries and AS/400 Technical Support


IBM disclaims all warranties, whether express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. By furnishing this document, IBM grants no licenses to any related patents or copyrights. Copyright (c) 1996,1997,1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 IBM Corporation. Any trademarks and product or brand names referenced in this document are the property of their respective owners. Consult the Terms of use link, and select the Copyright and trademark information link from the left navigation bar for trademark information.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Lim Hock-Chai
Sent: Thursday, November 08, 2007 10:15 AM
To: Midrange Systems Technical Discussion
Subject: RE: What determine the auth of ifs file created use CPYTOSTMF
command?


I don't recall it works like that. This seems to start to happen after
we upgrade to v5r3.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff Young
Sent: Thursday, November 08, 2007 10:06 AM
To: Midrange Systems Technical Discussion
Subject: Re: What determine the auth of ifs file created use CPYTOSTMF
command?

I beleive that by default it gets created with *NONE.
You need to use the CHGAUT command to grant *Public the required
authority.

Jeff Young
Sr. Programmer Analyst
IBM -e(logo) server Certified Systems Exper - iSeries Technical
Solutions V5R2 IBM Certified Specialist- e(logo) server i5Series
Technical Solutions Designer V5R3 IBM Certified Specialist-
e(logo)server i5Series Technical Solutions Implementer V5R3









----- Original Message ----
From: Lim Hock-Chai <Lim.Hock-Chai@xxxxxxxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Thursday, November 8, 2007 10:53:45 AM
Subject: What determine the auth of ifs file created use CPYTOSTMF
command?

Does anybody know what determine the auth of ifs file that created by
CPYTOSTMF command? I need it to be *public *all but it keep created
with *public *none.

thanks
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.