[zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)

2010-09-29 Thread Miles Nordin
 rb == Ralph Böhme ra...@rsrc.de writes:

rb The Darwin kernel evaluates permissions in a first
rb match paradigm, evaluating the ACL before the mode 

well...I think it would be better to AND them together like AFS did.
In that case it doesn't make any difference in which order you do it
because AND is commutative.  The Darwin method you describe means one
might remove permissions with chmod but still have access granted
under first-match by the ACL.  I just tested, and Darwin does indeed
work this way. :(

One way to get from NFSv4 to what I want is that you might add EVEN
MORE complexity and have ``tagged ACL groups'':

 * all the existing ACL tools and NFS/SMB clients targeting 
   the #(null) tag, 

 * traditional 'chmod' unix permissions targeting the #(unix) tag.  

 * The evaluation within a tag-group is first-match like now, 

 * The result of each tag-group is ANDed together for the final
   evaluation

When accomodating Darwin ACL's or Windows ACL's or Linux NFSv4 ACL's
or translated POSIX ACL's, the result of the imperfect translation can
be shoved into a tag-group if it's unclean.

The way I would implement the userspace, tools would display all tag
groups if given some new argument, but they would always be incapable
of editing any tag group except #(null).  Another chroot-like tool
would swap a given tag-group for #(null) for all child processes:

car...@awabagal:~/bar$ ls -v\# foo
-rw-r--r--   1 carton   carton 0 Sep 29 18:31 foo
 0#(unix):owner@:execute:deny
 
1#(unix):owner@:read_data/write_data/append_data/write_xattr/write_attributes
 /write_acl/write_owner:allow
 2#(unix):group@:write_data/append_data/execute:deny
 3#(unix):group@:read_data:allow
 
4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes
 /write_acl/write_owner:deny
 
5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
 :allow
car...@awabagal:~/bar$ chmod A+owner@:write_data:deny foo
car...@awabagal:~/bar$ ls -v\# foo
-rw-r--r--   1 carton   carton 0 Sep 29 18:31 foo
 0#(null):owner@:write_data:deny
   #
 0#(unix):owner@:execute:deny
 
1#(unix):owner@:read_data/write_data/append_data/write_xattr/write_attributes
 /write_acl/write_owner:allow
 2#(unix):group@:write_data/append_data/execute:deny
 3#(unix):group@:read_data:allow
 
4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes
 /write_acl/write_owner:deny
 
5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
 :allow
car...@awabagal:~/bar$ echo lala  foo
-bash: foo: Permission denied
car...@awabagal:~/bar$ chpacl baz ls -v\# foo
-rw-r--r--   1 carton   carton 0 Sep 29 18:31 foo
   #
 0#root:owner@:write_data:deny -- #root is what's mapped to 
#(null) at boot
   #
 0#(unix):owner@:execute:deny
 
1#(unix):owner@:read_data/write_data/append_data/write_xattr/write_attributes
 /write_acl/write_owner:allow
 2#(unix):group@:write_data/append_data/execute:deny
 3#(unix):group@:read_data:allow
 
4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes
 /write_acl/write_owner:deny
 
5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
 :allow
car...@awabagal:~/bar$ chpacl '(null)' true
chpacl: '(null)' is reserved.
car...@awabagal:~/bar$ chpacl baz chmod A+owner@:read_data:deny foo
car...@awabagal:~/bar$ chpacl baz ls -v\# foo
-rw-r--r--   1 carton   carton 0 Sep 29 18:31 foo
 0#(null):owner@:read_data:deny
   #
 0#root:owner@:write_data:deny
   #
 0#(unix):owner@:execute:deny
 
1#(unix):owner@:read_data/write_data/append_data/write_xattr/write_attributes
 /write_acl/write_owner:allow
 2#(unix):group@:write_data/append_data/execute:deny
 3#(unix):group@:read_data:allow
 
4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes
 /write_acl/write_owner:deny
 
5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
 :allow
car...@awabagal:~bar$ cat foo
-bash: foo: Permission denied
car...@awabagal:~bar$ chpacl baz cat foo  -- current tagspace is irrelevant to 
ACL evaluation
-bash: foo: Permission denied
car...@awabagal:~/bar$ ls -v\# foo
-rw-r--r--   1 carton   carton 0 Sep 29 18:31 foo
 0#(null):owner@:write_data:deny
   #
 0#baz:owner@:read_data:deny
   #
 0#(unix):owner@:execute:deny
 
1#(unix):owner@:read_data/write_data/append_data/write_xattr/write_attributes
 /write_acl/write_owner:allow
 2#(unix):group@:write_data/append_data/execute:deny
 3#(unix):group@:read_data:allow
 
4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes
 /write_acl/write_owner:deny
 
5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
 :allow

Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)

2010-09-29 Thread Nicolas Williams
Keep in mind that Windows lacks a mode_t.  We need to interop with
Windows.  If a Windows user cannot completely change file perms because
there's a mode_t completely out of their reach... they'll be frustrated.

Thus an ACL-and-mode model where both are applied doesn't work.  It'd be
nice, but it won't work.

The mode has to be entirely encoded by the ACL.  But we can't resort to
interesting encoding tricks as Windows users won't understand them.

Nico
-- 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)

2010-09-29 Thread Ralph Böhme
 Keep in mind that Windows lacks a mode_t.  We need to
 interop with Windows.

Oh my, I see. Another itch to scratch. Now at least Windows users are happy 
while me and mabye others are not.
-r
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)

2010-09-29 Thread Nicolas Williams
On Wed, Sep 29, 2010 at 03:09:22PM -0700, Ralph Böhme wrote:
  Keep in mind that Windows lacks a mode_t.  We need to
  interop with Windows.
 
 Oh my, I see. Another itch to scratch. Now at least Windows users are
 happy while me and mabye others are not.

Yes.  Pardon me for forgetting to mention this earlier.  There's so many
wrinkles here...  But this is one of the biggers; I should not have
forgotten it.

Nico
-- 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)

2010-09-29 Thread Nicolas Williams
On Wed, Sep 29, 2010 at 05:21:51PM -0500, Nicolas Williams wrote:
 On Wed, Sep 29, 2010 at 03:09:22PM -0700, Ralph Böhme wrote:
   Keep in mind that Windows lacks a mode_t.  We need to
   interop with Windows.
  
  Oh my, I see. Another itch to scratch. Now at least Windows users are
  happy while me and mabye others are not.
 
 Yes.  Pardon me for forgetting to mention this earlier.  There's so many
 wrinkles here...  But this is one of the biggers; I should not have

s/biggers/biggest/

 forgotten it.
 
 Nico
 -- 
 ___
 zfs-discuss mailing list
 zfs-discuss@opensolaris.org
 http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss