> FWIW, even some veteran VMers get caught by this. It is by no means a simplistic question or issue.
Absolutely, that's why some long-time VM's purchased and installed SafeSFS from Safe Software. It vastly reduces the number of GRANTs. IBM's scheme provides incredible levels of protection - far more than most customers ever need. The majority of time, all one needs is user or ACIgroup READ, or WRITE authorization to a resource. All that breaks down into SAFESFS syntax like the following from the help file: (c) Copyright Safe Software, Inc. 1998 ACCEPT +-USER-+ >>--ACCEPT--+------+-ReqUser----+--+-READ-----+-------------------------------> | | +-WRITE----+ +-ACIGROUP ReqGroup-+ +-CO-OWNER-+ +---------+ v | >--+-------+-fp:fs.--+------+-+--+----------------+-------------------------->< +-fn ft-+ +-dir.-+ +-(-MIXED--+---+-+ +-)-+ For example (with userids replaced): * - Allow user JQPUBLIC to examine user MJDOE's PUBLIC directory, * which is located off of MJDOE's filespace: * ACCEPT JQPUBLIC READ *:MJDOE.PUBLIC * or: * ACCEPT USER JQPUBLIC READ *:MJDOE.PUBLIC * * Caution: * - Adding an asterisk ('*') to the end of the root directory will * NOT authorize the root directory itself. For example, * ACCEPT USER JQPUBIC WRITE XXX01:SOMEDIR.* * Will not authorize access to SOMEDIR, itself - but to only to * sub-directories of SOMEDIR. ... there's more, which I have omitted... This is much easier to understand (it looks an awful lot like CA's VM:Secure rules!), and vastly reduces the number of authorizations. That makes backups run much faster, and Disaster Recoveries run much faster. Did I mention that it VASTLY simplifies SFS authorizations? ;-) If you're going to be managing more than a handful of SFS userids and grants, you owe it to yourself to check www.safesoftware.com to learn more. IMHO it's pretty (relatively) cheap, too! I don't derive any benefits of any kind in stating my opinions of SafeSFS. I'm just a happy customer, wanting to be sure that anyone new to SFS doesn't miss it just because they've never heard of it. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Martin Zimelis" <martin.zime...@gmail.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 08/18/2010 02:26 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: New to SFS Casey, First of all, this discussion assumes that you're working with a FILECONTROL directory (vs. a DIRCONTROL directory). See the discussion under CREATE DIRectory command for the differences. You need to look more carefully at the discussion of the GRANT AUTHority command. There are separate authorities/permissions for directories and files. For example, someone may have READ authority on a (sub)directory, but WRITE authority on (some) files in the directory. That could explain the behavior you're seeing. It all depends on what's been granted. The QUERY AUTH command can give you an idea of what authorities have been granted. FWIW, even some veteran VMers get caught by this. It is by no means a simplistic question or issue. Marty On Wed, Aug 18, 2010 at 2:33 PM, Casey Rhodes <crho...@tsys.com> wrote: > New to Shared File Sytems, so up fromt please forgive me if this is way to > simplistic for some of those here. > > I have enrolled a new user in the vmsys filepool called shared. And then > created directories under the shared top directory. I then granted a user > read access to these lower directories. When accessed by the user granted > read access the AUTH PF6 key shows this user only has read capabilities, > but user is still allowed to update the files. > > Dont know where to go from here. Sorry to bring the discussions down to > basics but dont find the CMS File Pool Planning, Administration and > Operations guide all that easy to use. > > > Any direction here would be appreciated. > > Casey > The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.