On Thu, Sep 30, 2010 at 02:55:26PM -0400, Miles Nordin wrote: > >>>>> "nw" == Nicolas Williams <nicolas.willi...@oracle.com> writes: > nw> Keep in mind that Windows lacks a mode_t. We need to interop > nw> with Windows. If a Windows user cannot completely change file > nw> perms because there's a mode_t completely out of their > nw> reach... they'll be frustrated. > > well...AIUI this already works very badly, so keep that in mind, too. > > In AFS this is handled by most files having 777, and we could do the > same if we had an AND-based system. This is both less frustrating and > more self-documenting than the current system. > > In an AND-based system, some unix users will be able to edit the > windows permissions with 'chmod A...'. In shops using older unixes > where users can only set mode bits, the rule becomes ``enforced > permissions are the lesser of what Unix people and Windows people > apply.'' This rule is easy to understand, not frustrating, and > readily encourages ad-hoc cooperation (``can you please set > everything-everyone on your subtree? we'll handle it in unix.'' / > ``can you please set 777 on your subtree? or 770 group windows? we > want to add windows silly-sid-permissions.''). This is a big step > better than existing systems with subtrees where Unix and Windows > users are forced to cooperate.
Consider this chronologically-ordered sequence of events: 1) File is created via Windows, gets SMB/ZFS/NFSv4-style ACL, including inherittable ACEs. A mode computed from this ACL might be 664, say. 2) A Unix user does chmod(644) on that file, and one way or another this effectively reduces permissions otherwise granted by the ACL. 3) Another Windows user now fails to get write perm that they should have, so they complain, and then the owner tries to view/change the ACL from a Windows desktop. Now what? Can the user in (3) fix the permissions from Windows? For that to be possible the mode must implicitly get recomputed when the ACL is modified. What if (2) happens again? But, OK, this is a problem no matter what, whether we do groupmasking, discard, or keep mode separate from the ACL and AND the two. ZFS does, in fact, keep a separate mode, and it does recompute it when ACLs are modified. So this may just be a matter of doing the AND thing and not touching the ACL on chmod. Is that what you have in mind? > It would certainly work much better than the current system, where you > look at your permissions and don't have any idea whether you've got > more, less, or exactly the same permission as what your software is > telling you: the crappy autotranslation teaches users that all bets > are off. No, currently you look at permissions that they reflect the ACL (with the group bits being the max of all non-owner@ and non-everyone@ ACEs). > It would be nice if, under my proposal, we could delete the unix > tagspace entirely: > > chpacl '(unix)' chmod -R A- . Huh? > but unfortunately, deletion of ACL's is special-cased by Solaris's > chmod to ``rewrite ACL's that match the UNIX permissions bits,'' so it > would probably have to stay special-cased in a tagspace system. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
