Subject: Re: [nfsv4] Connectathon2004, ACL report

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 16 Apr 2004 13:18:03 -0400

Sorry for the long-delayed response!

On Tue, Mar 30, 2004 at 10:36:35AM -0700, Wu Zheng wrote:
> The following attachment is a list of ACL related issues which are studied
> and discussed at Connectathon.

In future, could you just send this sort of thing as plain text in the
body of an email rather than as an html attachment?  That would make it
easier to respond to and discuss on a mailing list.

A few comments:

> Any ACL changes on a directory will only affect the
> ACL of its offspring that are created after the acl changes. When a child
> file or directory is created, it inherits its ACL from its parent. After
> the creation, the child's ACL and parent's ACL are independent from each
> other. Altering one will not effect the other.

My impression is that some implementors are going to propagate changes
immediately.  Based on previous discussions on the list, I believe the
concensus is to allow either behavior.

> File owner always has the right to read and write ACL even when ACL denies
> file owner permssion to read/write ACL.

Following the principal that "in all cases ...  the server must not
accept ACLs that appear to make the file more secure than it really
is",  I think the way to enforce this is to return NFS4ERR_ATTRNOTSUPP
(or NFS4ERR_INVAL?) to setattrs with ACLs that don't permit the owner to
modify the ACL, rather than silently allowing such modifications.

> Relationship between ACE4_DELETE and ACE4_DELETE_CHILD
> There are two permission mask bits which control
> the deletion of the a file and directory. One is the ACE4_DELETE_CHILD
> bit in the parent directory's ACL. The other one is the ACE4_DELETE bit
> in the ACL of the file to be deleted. There are two interpretations of
> the relationship between the two bits.
> A) A file/directory can be removed only if the
> process has both ACE4_DELETE_CHILD and ACE4_DELETE permissions.
> B) ACE4_DELETE overrides ACE4_DELETE_CHILD. When
> an ACL explicitly specifies ACE4_DELETE in ALLOW ACE(s) or DENY ACE(s),
> ACE4_DELETE take precedence over ACE4_DELETE_CHILD. If ACE4_DELETE is unspecified,
> then ACE4_DELETE_CHILD defines the permission. In the case both are not
> specified, deny is the default.
> AIX currently implements A). Hummingbird currently
> implements B). Netapp will implement B).

This disagreement makes accurate POSIX<->NFSv4 ACL mapping, and, for
that matter, mode bit/ACL synchronization, impossible.  If a client
supporting POSIX ACLs wishes to set an accurate ACL on a server using
(A), then POSIX mapped ACLs must always explicitly allow ACE4_DELETE.
If the server uses (B), then the client must never explicitly allow or
deny ACE4_DELETE.

So it's important to agree on the meaning of ACE4_DELETE.  I'm inclined
to take something like option (B), since Sergey Klyushin has told me
that this is what windows does, and because I don't think any other
platform has an established use for the DELETE bit.  (Someone correct me
if I'm wrong.)

Actually from the point of view of a POSIX ACL user, it'd still be OK
for a server to do (A), as long as it defaulted to granting DELETE
permissions when they aren't explicitly allowed or denied in an ACL.

In general I think it makes the most sense for POSIX ACL users to never
explicitly allow or deny mode bits that they can't interpret (like
DELETE or SYNCHRONIZE).

> Mode to NFS4 ACL mapping algorithm
> The follow is the mode bits to ACL mapping algorithm
> used by AIX. Similar algorithm is being discussed among connectathon attendees.
> OWNER@ always allow:
> ACE4_WRITE_ACL | ACE4_WRITE_ATTRIBUTES | ACE4_WRITE_NAMED_ATTRIBUTES
> | ACE4_READ_ACL | ACE4_READ_ATTRIBUTES | ACE4_READ_NAMED_ATTRIBUTES | ACE4_DELETE
> GROUP@ and EVERYONE@ always allow:
> ACE4_READ_ACL | ACE4_READ_ATTRIBUTES | ACE4_READ_NAMED_ATTRIBUTES | ACE4_DELETE

Note that on a server taking interpretation (B) for the DELETE bit, this
would have the unintended consequence of allowing unlinks of files
without write permissions on the parent directory.

The NFSv4<->POSIX ACL draft requires that the NAMED_ATTRIBUTES bits be
determined by the read and write bits, just because that appears to be
the way Linux filesystems do it.  Why are you doing it this way instead?

> When a UNIX server maps mode bit to NFS4 ACL, the
> ACE4_SYNCHRONIZE permission mask bit should be set for the ALLOW
> ACEs of OWNER@, GROUP@ and EVERYONE@.
> The ACE4_SYNCHRONIZE mask bit has no meaning to most
> UNIX servers. UNIX does not support threads to wait on a file close event.
> However, there is a possibility the SYNC behavior can be simulated on a
> windows client. The ACE4_SYNCHRONIZE permission might mean something to
> a windows client. Hummingbird developers request that we set the
> ACE4_SYNCHRONIZE bit in ALLOW ACEs of OWNER@, GROUP@ and EVERYONE@.

Could they explain why?  Would it be sufficient just to never set the
bit (either in allow or deny aces)?

--b.

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

---

From: Wu Zheng <[email-masked]>
Date: Wed, 21 Apr 2004 17:38:44 -0500

See comments bellow.

Wu Zheng
[email-masked]
Phone: (512) 838-0558    T/L: 678-0558
11400 Burnet Road,  Austin, TX 78758

> easier to respond to and discuss on a mailing list.

Will do

> concensus is to allow either behavior.

AIX and Netapps (Saadia) feel that it is preferable not to propagate the
changes.
Some vendors may choose to propagate the changes because of limitations in
their
implementation. We can identify who has implemented which option at the
next
Bakethon and document it.

> modify the ACL, rather than silently allowing such modifications.

What you are suggesting will be hard to implement (but not impossible).
We need to consider ACEs for all the groups that OWNER belongs to.
We need to consider the ACEs for EVERYONE@. We need to consider the
case the read/write acl permissions are unspecified (deny by default).
After considering all that and the ACL passes the test, when OWNER@ joins a
new group, or when the file OWNER changes, the OWNER may no longer have
read/write acl permission according to the file's ACL. In that case,
we still need to decide if OWNER has permission to read and write ACL when
the file's ACL does not grant the permission.

> explicitly allow or deny mode bits that they can't interpret (like

I understand your concern. we (AIX) need some time to think this over.
Meanwhile, I think it is good to document our behavior and make it known.

> the way Linux filesystems do it.  Why are you doing it this way instead?

You are right. We remapped the ACE4_WRITE_NAMED_ATTRIBUTES to write
permission and ACE4_READ_NAMED_ATTRIBUTES to read permission. Users will
have ACE4_WRITE_NAMED_ATTRIBUTES and ACE4_READ_NAMED_ATTRIBUTES permissions
when they have read and write permissions.

> bit (either in allow or deny aces)?

Unix servers really do not care about the ACE4_SYNCHRONIZE bit. Here we
are trying to accommodate what windows clients need. In AIX implementation,
when a permission is neither allowed nor denied, it is denied by default.
It is likely that the same is true for windows clients. If that is the
case,
and if windows clients want to allow ACE4_SYNCHRONIZE by default, then
we have to set the bit.

>From talking to Sergey Klyushin, I think he wants us to allow
ACE4_SYNCHRONIZE by default.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 21 Apr 2004 19:35:08 -0400

On Wed, Apr 21, 2004 at 05:38:44PM -0500, Wu Zheng wrote:
> > > File owner always has the right to read and write ACL even when ACL
> > > denies file owner permssion to read/write ACL.
> >

I agree, that would be a mess.

All I'd consider would be a simple check for whether there is an OWNER@
ACE which allows the WRITE_ACL bit, and which precedes any ace that
denies that bit.

Or maybe, for the sake of clients that don't use OWNER@, you could also
consider an acl acceptable if the acl permits some named user to write
acls.  That way there would still be someone could always delete the
file, even if not the owner.  But again you'd want to insist that this
be done by an ace that isn't preceded by any aces denying the WRITE_ACL
bit; otherwise a change in group membership or change of the owner might
later end up causing a problem.

> > If the server uses (B), then the client must never explicitly allow or
....
> Meanwhile, I think it is good to document our behavior and make it known.

We do need to come to some agreement on this soon.  I think this might
be the only thing holding up the ability to handle mode-bit and
posix-acl mapping in a completely interoperable way.

> when they have read and write permissions.

Oh good, I'm glad everyone seems to agree here.

Thanks for following up on this!--b.

---

From: Wu Zheng <[email-masked]>
Date: Fri, 23 Apr 2004 14:38:54 -0500

> ACE which allows the WRITE_ACL bit, and which precedes any ace that

Very interesting approach. I have to say this one is simple and does make
sure owner always has permission to read and write acl. But it requires
that a user always specify an ace which allows owner to read/write acl.
As a result, users may be trained to always start an acl with the ACE
"allow OWNER@ read/write acl."

An average user is likely to use the following acl with one ace.
    allow EVERYONE@ read data, read named attribute, read attribute, read
acl.
The user will be frustrated when it is rejected as an invalid acl with very
little
information about why.

I hope that we agree that at access checking time, owner always has
permission
to read/write acl. The question is that when we store an acl, do we check
if the
acl allows owner to read/write acl and what kind of check is done.

Right now, I have see three options:
A) allow the file owner to read/write acl silently. Put no restriction on
acl.
B) Put a restriction on ACL to gurentee OWNER@ always has the permission to
read/write acl. For example: 1) "check for whether there is an OWNER@ ACE
which allows the WRITE_ACL bit, and which precedes any ace that
denies that bit."
C) limited check is done to reject some invalid acls. This checking does
not
have to reject all the acls which deny owner's right to read/write acl.
It may even reject some acl which allows owner's right to read/write acl.
Each vendor may have a different algorithm.

AIX (jfs2 and GPFS file system) is currently trying to implement C).
The algorithm is that an acl is rejected when there is an ace which denies
OWNER@
permission to read/write acl. To keep it simple, the order of aces are not
considered. An acl may have an ace which denies the permission after an ace
which allows the permission. As a result of the algorithm, such acl is
rejected even though it does allow owner to read acl. This algorithm
is a compromise between trying to be right and practical.

Personally I like A), because it is consistent and simple for users and
developers.
But I understand that B) conforms to the protocol and C)is attempted and
maybe
preferred by some people.

It is hard to make everyone do the same thing. But it is good to put
options
on the table and document who is doing what. If I attend Bakecthon, I will
update my document to describe the options in detail and write down each
vendor's approach.

> later end up causing a problem.

Agree. When a client does not use OWNER@, chown becomes a problem.
By the way, root always has the permission for all operations.

> posix-acl mapping in a completely interoperable way.

I will try to follow up on this issue. But it will be sometime before I can
get back to you.

Wu Zheng