With a DIRC, SFS security is pretty much like a minidisk. For your Y-disk you'd issue a "GRANT AUTH dirid TO PUBLIC (DIRREAD" and everyone can read any file on it. For a filecontrol directory one must indeed have a grant for the directory and for each file.
2007/6/14, David Boyes <[EMAIL PROTECTED]>:
> a) Has anyone else done this as (1) a form of housecleaning or (2) a generally good idea > for the Y-disk? Do you have any guidance for those about to trod upon the road "less > traveled by"? I know of a couple sites that did this. The major complaints I heard were: 1) install tools that blindly link MAINT 19E and don't tell you or fail reasonably when it doesn't work (or worse yet, when it succeeds and they dump random crap on there w/o telling you) 2) loss of the benefit of the YDISK saved segment, although that was a while back when storage was still a lot more constrained. It would be nice to never see the SSTAT/YSTAT mismatch message again... 3) The complexity of managing ACLs for large numbers of CMS users using the built-in tools. 4) CMS products that expect their important bits to be on the Y disk and that rearrange their environment internally after starting up, releasing anything but what they expect to be there. With less CMS workload and fewer CMS-based services, most of the things that used to be a PITA for this may be controllable now. > b) Why is it that filemode 0 (zero) files appear in a read-only SFS filespace? OK, the > "ACCESS" doc does not mention MODE0 for anything but MDISKs. But why would it even be > designed to show filemode 0 in read-only mode? IMHO, that's what file-level ACLs/permissions are for. The Mode 0 convention is a hack invented because minidisks didn't have ACLs. I think you could simulate the same effect as mode 0 by using group-based security grants for "public" files. If you need to remove a file from public view, you grant access to a temporary group consisting of all the users that have the directory accessed at the time you remove the file and then revoke access for all the "normal" groups. The "exception" group should get cleared and destroyed at the next IPL. Be sure to read the discussion of the impact of the GRANT PUBLIC access parameter in the SFS admin guide before you enable PUBLIC access to that pool; it's probably not what you want if you want this to work. This approach plays hell with the size of the VMSECURE database and SFS rules database unless you have well defined groups of users, but I'm sure John can sell you SafeSFS to manage that. > c) The Y-disk contains a bunch of "hidden" files (anything other than filemode Y2 is hidden > by the standard "ACCESS 19E Y/S * * Y2"). That was pretty handle to reduce visible clutter > for things like compilers (HLASM, COBOL2, etc.) and other installation-specific files. Did > I miss something in SFS that would let us continue to "hide/reduce clutter" by filemode in > an SFS filespace? See above. In a file-level SFS directory, you shouldn't even see files you don't have permission for. Not quite as easy to manage, but gives the same effect.
-- Kris Buelens, IBM Belgium, VM customer support
