Subject: [nfsv4] [FYI] NFSv4 ACLs on Linux: Design Documentation

From: Andreas Gruenbacher <[email-masked]>
Date: Wed, 6 Sep 2006 16:59:28 +0200

I have the design documentation for the Linux implementation of NFSv4 ACLs 
reasonably complete now; it is available at:

  http://www.suse.de/~agruen/nfs4acl/
      draft-gruenbacher-nfsv4-acls-in-posix-00.html

The first part of the document discusses how NFSv4 ACLs relate to POSIX. The 
second part describes algorithms which can be used to implement NFSv4 ACLs in 
a POSIX compliant way.

This design is based on file masks as proposed in [1]. Independent of that, 
the algorithm to apply a file mode to an ACL can be used whether or not file 
masks are used.

The code at http://www.suse.de/~agruen/nfs4acl/ is a complete and functional 
implementation of this design.

I would like to encourage people to have a look at the design document as well 
as the implementation.

Regards,
Andreas

[1] A. Gruenbacher and J. Fields: NFSv4 file_masks Attribute,
    http://www.ietf.org/internet-drafts/
      draft-gruenbacher-nfsv4-file-masks-00.txt

-- 
Andreas Gruenbacher <[email-masked]>
Novell / SUSE Labs

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

---

From: Sam Falkner <[email-masked]>
Date: Wed, 06 Sep 2006 17:51:21 -0600

>       draft-gruenbacher-nfsv4-acls-in-posix-00.html

Sections 3.2 and 4.3/4.2.2 recommend computing a mode in a way that  
is incompatible with RFC 3530.  My impression from the meetings in  
Broomfield was that you were going to implement to be compliant with  
the 3530 definition of the mode attribute.  Did I misunderstand?

- Sam

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 7 Sep 2006 13:59:32 -0400

On Wed, Sep 06, 2006 at 05:51:21PM -0600, Sam Falkner wrote:
> >I have the design documentation for the Linux implementation of  
> >NFSv4 ACLs reasonably complete now; it is available at:
> >
> is incompatible with RFC 3530.

Yeah.  Some existing servers (e.g. the current linux server) are already
incompatible in that way, though.

While there'd be advantages to achieving concensus on this, it isn't
really required for interoperability, and I don't think it's worth the
trouble at this point.

That's why Andreas is posting this as informative design documentation
rather than proposed spec language.

> My impression from the meetings in  Broomfield was that you were going
> to implement to be compliant with  the 3530 definition of the mode
> attribute.  Did I misunderstand?

We did decide to at least prototype the write-through behavior.
Andreas, having done so, doesn't seem happy with it, though the kernel
patches he submitted recently actually allow either behavior.

--b.

---

From: Andreas Gruenbacher <[email-masked]>
Date: Fri, 8 Sep 2006 15:39:43 +0200

On Thursday, 07 September 2006 01:51, Sam Falkner wrote:
> > NFSv4 ACLs

At the meeting, there was no consensus about the most reasonable technical 
approach. A set of preferred behaviors was identified, including a preferred 
way how to calculate file permission bits from an ACL. The majority vote was 
to not propose a change to the RFC3530 definition.

We also agreed that I would try to implement the preferred behaviors, and 
propose them to the Linux community. I tried to implement the mode computation 
behavior that rfc3530 presecribes, and it has become even more clear in the 
process that the result would be inconsistent with POSIX.

I'm not saying that the rfc3530 behavior violates POSIX --- the POSIX 
definitions can be stretched far enough so that the rfc3530 behavior is 
within the bounds of the specification --- but the result doesn't make a lot 
of sense. ACLs like

	user@dom:READ_DATA/WRITE_DATA::ALLOW

or

	group@dom:READ_DATA/WRITE_DATA:IDENTIFIER_GROUP:ALLOW

would compute to a mode of 0. This is particularly confusing with a user@dom 
or group@dom owner or owning group.

Setting the file mode to 0 in a SETATTR clearly should have a different effect 
than allowing the above accesses. The rfc3530 algorithm for computing a mode 
from an ACL does not match the algorithm for setting the mode in SETATTR, 
which makes no sense.

I cannot propose something to the Linux community that doesn't make sense only 
to comply with a majority vote recommendation without technical arguments 
backing that decisison. So we'll have to differ in this aspect I'm afraid. 

Andreas

---

From: Andreas Gruenbacher <[email-masked]>
Date: Fri, 8 Sep 2006 15:43:53 +0200

> patches he submitted recently actually allow either behavior.

I simply don't know which of the two options (write-through or not) is best, 
or whether someting else would make more sense. We'll hopefully learn from 
experience.

Andreas

---

From: Sam Falkner <[email-masked]>
Date: Fri, 08 Sep 2006 12:02:18 -0600

> backing that decisison. So we'll have to differ in this aspect I'm  

I'm not trying to convince Andreas.  This is just for the record, in  
case anyone else is reading this thread.

Here's a technical argument for the RFC 3530 compliant way to compute  
a mode from an ACL.

I assume everyone agrees that a mode cannot reflect all the  
information in an ACL.  This leaves you with a choice on how to  
compute the mode.  You can try to show the mode as a superset of  
every permission granted in the ACL (like the withdrawn POSIX-draft  
ACL spec says), or you can use the mode to show read/write/execute  
for owner/group/other (like RFC 3530 says).

But the POSIX-draft ACL algorithm can only show a superset of  
permissions for read, write, and execute.  When you carry the POSIX- 
draft ACL algorithm to NFSv4 ACLs, it breaks down.  A file with this  
ACL:

OWNER@:READ_DATA/WRITE_DATA::ALLOW
GROUP@:::ALLOW
EVERYONE@:WRITE_ACL::ALLOW

would give a mode of 600, but note that any random entity can change  
the permissions.  So if you really want to know all the permissions  
of a file, you have to look at the ACL.

On the other hand, consider a file in group "staff" with this ACL:

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

The POSIX-draft ACL algorithm gives a mode of 640.  Inevitably,  
someone in group "staff" tries to read the file, gets denied, does  
"ls -l", and calls the help desk.  This generated enough customer  
complaints at Sun that we abandoned this behavior years ago, years  
before NFSv4 was rolled out, even on filesystems with POSIX-draft  
ACLs.  Since then, no complaints.

I see the merits of the POSIX-draft ACL algorithm, and I see the  
merits of the RFC 3530 algorithm.  Neither affords "total security"  
by reading only the mode attribute.  Customer support data indicates  
a preference to the RFC 3530 algorithm.

I have no intention of debating this further.

- Sam

---

From: Andreas Gruenbacher <[email-masked]>
Date: Sat, 9 Sep 2006 10:50:46 +0200

On Friday 08 September 2006 20:02, Sam Falkner wrote:
> This generated enough customer complaints at Sun that we abandoned this
> behavior years ago, years before NFSv4 was rolled out, even on filesystems
> with POSIX-draft ACLs.  Since then, no complaints.

IIRC Solaris implements write-through for its variant of POSIX-draft ACLs 
(i.e., changing the group file permissions changes both the mask:: and 
group:: entries), and does /not/ change the way how the mode is computed.

Andreas

---

From: "J. Bruce Fields" <[email-masked]>
Date: Sat, 9 Sep 2006 19:00:33 -0400

> group:: entries), and does /not/ change the way how the mode is computed.

I think it's my fault for conflating the two issues; apologies.

--b.