On Fri, February 26, 2010 12:45, Paul B. Henson wrote: > I've already posited as to an approach that I think would make a pure-ACL > deployment possible: > > > http://mail.opensolaris.org/pipermail/zfs-discuss/2010-February/037206.html > > Via this concept or something else, there needs to be a way to configure > ZFS to prevent the attempted manipulation of legacy permission mode bits > from breaking the security policy of the ACL.
It seems to me that it should depend. chown ddb /path/to/file chmod 640 /path/to/file constitutes explicit instructions to give read-write access to ddb, read access to people in the group, and no access to others. Now, how should that be combined with an ACL? I'll tell you, if I type that and then find I (I'm "ddb") *can't* read the file, I'm going to be REALLY unhappy. Which parts of what those commands say to do are "explicit" and should take precedence, and which parts are accidental and shouldn't override anything? When using the octal number form, I don't think you can tell. (If I type "chmod o-rwx", I think I've been exactly explicit about what I want, and I think I should get it if I have permission.) I guess it shouldn't be unexpected that ACLs, which are clearly much more powerful than basic permissions, are also more complicated. Additional power very often arrives accompanied by more complexity. The concept of having parts of a filesystem designated ACL-only and parts designated permissions-only leads to a total nightmare for utilities, applications, and admin scripts of all kinds, so I don't think that can be the answer. Maybe you could make some rules, though. For example, off the top of my head it seems reasonable that changes to permissions for "other" should not override ACL entries for specific users. Changes to permissions for "owner" SHOULD override ACL entries for the user that's the same as the current owner, if any exist. I'm not terribly sanguine about coming up with a set of rules that avoids disaster and avoids surprise and is possible to keep in your head, though. -- David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
