> 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" <[email protected]>
Sent by: "The IBM z/VM Operating System" <[email protected]>
08/18/2010 02:26 PM
Please respond to
"The IBM z/VM Operating System" <[email protected]>
To
[email protected]
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 <[email protected]> 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.
