Subject: Re: [nfsv4] CIFS friendly ACL/mode algorithm

From: Andreas Gruenbacher <[email-masked]>
Date: Sat, 2 Sep 2006 18:47:24 +0200

On Wednesday 30 August 2006 22:14, Sam Falkner wrote:
> ** This algorithm compared with a "mask attribute"
>
> If a new "mask attribute" were added to the NFSv4 protocol, and a
> server implemented such an attribute, it could stick with ACEs A1,
> A2, and A3, without ever needing to have A0, D1, or D2. In such a 
> scheme, mode 705 would look like (omitting bits beyond read, write,
> and execute):
>
> OWNER@:READ_DATA/WRITE_DATA/EXECUTE::ALLOW
> GROUP@:::ALLOW
> EVERYONE@:READ_DATA/EXECUTE::ALLOW

With the mask proposal, the ACL remains exactly the same as it was before, and 
both access check algorithms outlined in the "(acl, masks) pairs" mail make 
sure that no user is granted more permissions that the masks allow.

The above ACL doesn't reflect the permissions that the access check algorithm 
would grant in this case; this ACL is more permissive. A better matching ACL 
would be:

  OWNER@:READ_DATA/WRITE_DATA/EXECUTE::ALLOW
  GROUP@:READ_DATA/EXECUTE::DENY
  EVERYONE@:READ_DATA/EXECUTE::ALLOW

> [...] So a server implementing this proposed mask attribute still has to
> solve the problem of representing mode 705 as an ACL.

Yes. The (acl, masks) mail is explicit about the fact that an ACL GETATTR must 
return an ACL that grants no more than what the (acl, masks) pair grants.

Andreas

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Andreas Gruenbacher <[email-masked]>
Date: Sat, 2 Sep 2006 19:30:38 +0200

On Wednesday 30 August 2006 22:14, Sam Falkner wrote:
> Here is an outline of an algorithm that is an alternative to the one
> currently in Section A.3 of draft-ietf-nfsv4-minorversion1-06.

I would prefer to have neither the algorithm in 
draft-ietf-nfsv4-minorversion1-06 nor this new algorithm in the NFSv4.1 spec: 
both have corner cases that don't follow from requirements. I suggest to move 
the algorithms to a separate I-D.

> * Applying a mode to an existing ACL
>
> Okay, now what do we do if we are applying a mode to a file that
> already has an ACL?  Maybe it's an ACL on a pre-existing file, or
> maybe it's a newly created file that inherited an ACL.
>
> First step, remove all ACEs with a "who" value of OWNER@, GROUP@, or
> EVERYONE@, a type of ALLOW or DENY, and having the INHERIT_ONLY_ACE
> flag clear.

What happens to the following ACL after a chmod to 0770? It seems that 
[email-masked] will gain WRITE_DATA/EXECUTE access.

  OWNER@:READ_DATA/WRITE_DATA/EXECUTE::ALLOW
  GROUP@:READ_DATA/WRITE_DATA/EXECUTE::ALLOW
  EVERYONE@:READ_DATA/WRITE_DATA/EXECUTE::DENY
  [email-masked]:READ_DATA/WRITE_DATA/EXECUTE::ALLOW

> Next, we throttle the ACL to the group permissions.  Examine all ACEs
> of type ALLOW with the INHERIT_ONLY_ACE flag clear.  For each ACE, if
> MODE4_RGRP is not set, we clear READ_DATA.  If MODE4_WGRP is not set,
> we clear WRITE_DATA and APPEND_DATA.  If MODE4_XGRP is not set, we
> clear EXECUTE.  Optionally, you may clear other frightful bits, such
> as WRITE_OWNER.  When this is done, we refer to this ACL as <modified-
> ACL>.
>
> Finally, we lay the result out thus:
>
> A0, D1, D2, <modified-ACL>, A1, A2, A3.

What happens to this ACL after a mode SETATTR to 0777? It seems that 
[email-masked] will gain WRITE_DATA/EXECUTE access.

  OWNER@:READ_DATA/WRITE_DATA/EXECUTE::ALLOW
  [email-masked]:READ_DATA::ALLOW

> [...]
> If we set any bits in a DENY ACE where IDENTIFIER_GROUP was set, or
> for a special "who" (e.g. my personal favorite, "DIALUP@"), then we
> need to add the A0 ACE to the front of the ACL.  Instead of doing
> that, you could only use DENY ACEs for ordinary users, not groups or
> special "who" values.  For groups or special "who" values, just clear
> the access_mask bit in the ALLOW ACE.  Is this worth doing?

It would be another special case non-obvious to users that needed to be 
documented.

IMO we should not bother Windows users with any of this masking stuff at all.

> [...]
> Another difference is that the Section A.3 algorithm permits one to
> have an ACE such as:
>
> EVERYONE@:READ_ACL::DENY
>
> persist beyond setting a new mode.  If this is really desirable, then
> change the first step in this algorithm.  Rather than delete OWNER@,
> GROUP@, and EVERYONE@ ACEs, simply clear the bits READ_DATA,
> WRITE_DATA, APPEND_DATA, and EXECUTE.

It wouldn't prevent permission elevation in the above two cases.

> [...]
> - or, if you decide to implement the "preserve information" option -
>
> [email-masked]:READ_DATA/WRITE_DATA::DENY
> [email-masked]:READ_DATA/WRITE_DATA::ALLOW
> OWNER@:READ_DATA/WRITE_DATA/WRITE_ATTRIBUTES/WRITE_NAMED_ATTRS/
> WRITE_ACL/WRITE_OWNER::ALLOW
> GROUP@:::ALLOW
> EVERYONE@:READ_ATTRIBUTES/READ_NAMED_ATTRS/READ_ACL/SYNCHRONIZE::ALLOW

Not good if [email-masked] is the owner.

Andreas