RE: _C_IFS_FOPEN

Thank you Vernon.  This should be listed under security or IFS
authorities, not buried in Unix-style API hand book.  It should also be
part of the public doc's not registered base.  Hopefully this will help
others in the future.


Christopher Bipes

IS Director

CrossCheck, Inc. 

707.586.0551, ext. 1102

707.585.5700  FAX

Chris.Bipes@xxxxxxxxxxxxxxx
www.Cross-Check.com



Notice of Confidentiality: This e-mail, and any attachments thereto, is
intended only for use by the addressee(s) named herein and may contain
legally privileged and/or confidential information.  If you are not the
intended recipient of this e-mail, you are hereby notified that any
dissemination, distribution or copying of this e-mail, and any
attachments thereto, is strictly prohibited.  If you have received this
e-mail in error, please immediately notify me by e-mail (by replying to
this message) or telephone (noted above) and permanently delete the
original and any copy of any e-mail and any printout thereof.  Thank you
for your cooperation with respect to this matter.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vernon Hamberg
Sent: Friday, November 25, 2005 4:44 AM
To: Midrange Systems Technical Discussion
Subject: Re: _C_IFS_FOPEN

Chris

I went digging around and finally found something in the open()
Unix-style API, where the bit about "Each directory in the path" is
relevant.

Authorization Required for open() (excluding QSYS.LIB, independent ASP
QSYS.LIB,and QDLS)
Object Referred to                                      Authority 
Required      errno
Each directory in the path name preceding the object to be 
opened       *X      EACCES
Existing object when access mode is O_RDONLY                    *R
EACCES
Existing object when access mode is O_WRONLY                    *W
EACCES
Existing object when access mode is O_RDWR                      *RW
EACCES
Existing object when O_TRUNC is 
specified                               *W      EACCES
Parent directory of object to be created when object does not exist 
and O_CREAT is specified    *WX     EACCES

I like to think of directories as analogous to libraries and files to
objects. You need execute authority to a library in order to see objects
in that library, IIRC. Directories would be similar, except that each
directory needs execute authority, as stated above. It seems this is a
safe enough situation, as it takes write *W authority to a directory in
order to add objects to it, right?

This analogy, as far as it goes, also helps me when using the SAV and
RST commands. E.g., saving in the IFS without using an asterisk is like
SAVLIB, and you can restore the directory, even if it does not exist on
the target machine. If you specify files, even with '*', you do not get
the directory saved along with the objects. This is just like SAVOBJ,
where the containing library is not saved along with the objects.

Finally, a little more digging at the support site found this link

http://www-1.ibm.com/support/docview.wss?uid=nas1e3dc97d7f1aeaf348625685
f005c6263

entitled "Integrated File System Authority Considerations". It's part of
the registered knowledge base, but the link might get around that