Subject: Re: [nfsv4] Last Call for RFC 3530 BIS (ending on May 3rd)

From: Thomas Haynes <[email-masked]>
Date: Mon, 15 Aug 2011 10:48:15 -0500

I'm hesitant to change these.

http://www.ietf.org/mail-archive/web/nfsv4/current/msg01350.html

3.3.1 ACE4_READ_NAMED_ATTRS, ACE4_READ_ATTRIBUTES and ACE4_READ_DATA

In the table below,

A = ACE4_READ_ATTRIBUTES
N = ACE4_READ_NAMED_ATTRS
D = ACE4_READ_DATA

The values that are given represent the presence or absence of the mask in an ALLOW ACE.

		D = 0                    D = 1
---------------------------------------------------------------
N = 0 / A = 0   NFS4ERR_ATTRNOTSUPP (1)  NFS4ERR_ATTRNOTSUPP (2)
---------------------------------------------------------------
N = 0 / A = 1   SUPPORTED (3)            NFS4ERR_ATTRNOTSUPP (4)
---------------------------------------------------------------
N = 1 / A = 0   NFS4ERR_ATTRNOTSUPP (4)  NFS4ERR_ATTRNOTSUPP (1)
---------------------------------------------------------------
N = 1 / A = 1   NFS4ERR_ATTRNOTSUPP (4)  SUPPORTED

(1) This is not supported because ACE4_READ_ATTRIBUTES is false and as
    the I-D says, every ACE must have ACE4_READ_ATTRIBUTES and
    ACE4_READ_ACL set.
(2) In UNIX/POSIX there is no way to enforce this.  You can't not have
    read permissions on the attributes of a file, but have read permissions
    on the data.
(3) An example of this is that a regular user doesn't have read
    permissions on /etc/shadow, but ls -l still works.
(4) In Solaris UFS, the authority to read named attributes is the same
    as the authority to read the file data.

In summary, these combinations are SUPPORTED:
    ACE4_READ_NAMED_ATTRS=0
    ACE4_READ_ATTRIBUTES=1
    ACE4_READ_DATA=0

and

    ACE4_READ_NAMED_ATTRS=1
    ACE4_READ_ATTRIBUTES=1
    ACE4_READ_DATA=1

Any other combination of these three masks will fail with NFS4ERR_ATTRNOTSUPP.
...

(2) In Solaris UFS, the authority to write named attributes is the same
    as the authority to write the file data.

On Jul 22, 2011, at 2:10 PM, Mike Eisler wrote:

> "ACE4_READ_NAMED_ATTRS
>      Operation(s) affected:
>         OPENATTR"
> READ too, correct?

Given the table above, ACE4_READ_DATA *must* always be set when
this is set. And it covers READ.

>   "ACE4_WRITE_NAMED_ATTRS
>      Operation(s) affected:
>         OPENATTR"
> WRITE too, correct?

ACE4_WRITE_DATA must also always be set and it covers WRITE.

I'm taking this to mean that ACE4_READ_NAMED_ATTRS and ACE4_WRITE_NAMED_ATTRS
are permissions for the user to be able to traverse/read the named attribute "directory" and
to create a new named attribute in it. The ACE4_READ_DATA and ACE4_WRITE_DATA
are permissions to read and write the data portion.

So, if a client created a new named attribute for a file and cached the corresponding
FH, ACE4_WRITE_NAMED_ATTRS could be removed for that named attribute, but the
client could still read/write data because it has the FH.

Kinda analogous to POSIX semantics on an open file, no?