--On Monday, March 01, 2010 03:21:42 PM -0600 Nicolas Williams <Nicolas.Williams at sun.com> wrote:
> On Fri, Feb 26, 2010 at 03:00:29PM -0500, Miles Nordin wrote: >> >>>>> "nw" == Nicolas Williams <Nicolas.Williams at sun.com> writes: >> >> nw> What could we do to make it Re: [zfs-discuss] Who is using ZFS ACL's in production?easier to use ACLs? >> >> 1. how about AFS-style ones where the effective permission is the AND >> of the ACL and the unix permission? You might have to combine this AFS applies its ACL, and the owner rwx bits on files (to everyone), and that's it. It doesn't care who the owner and group are (*). New directories inherit the ACL's of their parents. The only thing that manipulates AFS ACL's are the interfaces explicitly intended for that purpose. We've found this to work fairly well, with a few specific issues: - As someone pointed out, we don't have ACL's on individual files. This is a limitation we'd like to eventually fix. - There is no ability to set the inherited ACL for new subdirectories to something other than the ACL of the parent. This means, for example, you can't have a user home directory volume whose top-level gives x (in AFS, l) to everyone without new subdirs inheriting that. This is also something we'd like to fix. - Tools which second-guess access rights and refuse to offer or attempt operations they don't think the user can do get confused. Such tools are broken, and should be fixed. (*) Well, mostly it doesn't. To allow dropboxes to work sanely, under certain circumstances some rights are implied for a file's owner. For example, if you have "insert" access on a directory, you implicitly have "read" and "write" ACL rights on files you own; this is necessary because the server is stateless and so does not know what files a client has "open".
