On Thu, 25 Feb 2010, Marion Hakanson wrote: > It's not easy to get them right, and usually the hardest task is in > figuring out what the users want, so we don't use them unless the users' > needs cannot be met using traditional Unix/POSIX permissions.
We've got a web GUI that hides the complexity from end users, pretty much they see a list of files/directories, and pick users/groups with read only or read/write. We offer access to central user/group space via CIFS (currently samba in s10, with an eye towards opensolaris/in-kernel server), web, scp/sftp, kerberized NFSv4, and interactive unix login. The web server enforces ACL's, so users can restrict their web content by them. We've had a similar environment based on DCE/DFS for over 10 years (we're just about ready to shut that down, having completed migrating everything over) and our users have become quite acclimatized to the flexibility that this gives them to set access control once and have it respected regardless of access protocol. > and using inheritance to propagate them to any new items which are added > to shared areas. What protocols/access methods are used to get to the underlying zfs filesystem? The main ACL problem we've having now (having resolved most of them, yay) is interaction with chmod() and legacy mode bits, and the disappointing ease with which an undesired chmod can completely destroy an ACL. I finally ended up having to preload a shared library that disables chmod() into samba, which resolved our issues for CIFS. I still haven't found a way to keep users' ACL's from being wiped by rogue non-ACL aware command/utilities (including, as it turns out, Solaris' own chgrp command). Unfortunately, there's currently no global way to prevent manipulation of legacy mode bits from destroying ACL's. I've been working around particular instances of the problem (such as the preloaded shared library for samba, or using "chown :<group>" rather than chgrp), but it's a losing battle. There are 40 odd years of non-ACL aware stuff out there, it's intractable to try and fix it all on a case by case basis. Given ZFS's description as having a "pure acl" model, it really seems there should be some way to prevent those ACL's from getting wiped out at the drop of a chmod. > The scripting also (sorta) covers the problem that most backup and file > transfer utilities are not capable of backing up and restoring the > NFSv4-style ACL's on ZFS. We have a central Netbackup deployment. Supposedly it supports ZFS ACL's, although I've never actually tested that. I suppose I should at some point 8-/. If we can't find some clean way to maintain ACL sanity, we might have to start storing ACL's in metadata files (maintained in lockstep by our web control app), and having a job run around and restore broken ACL's on files/directories on an ongoing basis. That would be pretty kludgy :(, but better than sensitive data suddenly becoming world readable because somebody's favorite editor feels the need to chmod a file after creation to match the permissions it thinks it should have had based on the umask. Talk about a security deficiency <sigh>. Thanks for the info... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
