Re: [nfsv4] NFSv4 <-> POSIX-draft ACL interoperability

Hi Bruce and others.

Comments inline...

Thanks,
Lisa Week
Sam Falkner

J. Bruce Fields wrote:
> On Wed, Dec 01, 2004 at 01:34:00PM -0700, Sam Falkner wrote:
> 
>>Currently, Solaris does not set the ACE4_DELETE mask on any ACEs.  If a
>>Solaris client or server receives an ACL with ACE4_DELETE on any ACEs,
>>it fails; server returns NFS4ERR_ATTRNOTSUPP, client gives ENOTSUP and
>>it fabricates an ACL from the mode bits of the file.
> 
> 
> I don't understand the description of the client's behaviour.  If an
> application asks for an ACL, surely the client can't both return
> ENOTSUP and return the fabricated ACL at the same time?

Yes, this is a bit odd, but right now in Solaris, we have a requirement 
that the calls to get an acl must not fail.  The ENOTSUP is never seen 
by the user when using the Solaris system call (acl/facl) to get an acl.

> 
> 
>>1.1.1 Changes we could make to allow for better interoperability
>>
>>Server
>>
>>Solaris would ignore ACE4_DELETE on any ACEs in any ACL it receives.
>>It would continue to produce ACLs without ACE4_DELETE set on any of its
>>ACEs.  This would allow Solaris to be less strict on the ACLs it
>>accepts; the drawback is that a client could set an ACL with
>>ACE4_DELETE on some of its ACEs, but a subsequent get would not receive
>>the same ACL that was set.
> 
> 
> In the case of ACE4_DELETE set in a DENY ace, this would be a violation of
> "the guiding principle is that the file not appear to be more secure
> than it really is." (5.11.3).  Does this scare anybody, or does nobody
> care?
> 

To be honest, we'd prefer to keep Solaris' current behavior, but as you 
know, this really causes problems for IBM since they must have 
ACE4_DELETE and ACE4_DELETE_CHILD ALLOWed in order to delete a file. 
Right now, on a brand new file, an IBM server sends ACLs with 
ACE4_DELETE in the ALLOW ACE's.  Because of this our client is unable to 
even get an ACL from an IBM server.  Seems pretty serious...

Question for IBM:  By default, does your client place ACE4_DELETE in any 
ACE's upon setting an ACL?  If yes, with the current Solaris behavior, 
an IBM client would not be able to set an acl on a Solaris/UFS server.

> 
>>1.4 Linux/CITI
>>
>>???
> 
> 
> Our server returns -EINVAL if you send an ACE with DELETE set.
> Permissions to unlink are determined in the traditional way (by
> consulting write permissions on the directory).  The posix getfacl
> utility on our client will return an error if the DELETE bit is set in
> any ACL, and the posix setfacl will never send an ACE with DELETE set.

This is the same as Solaris' current behavior except for the fact that 
our server will return NFS4ERR_ATTRNOTSUPP if you send an ACE with 
ACE4_DELETE set. (That may be what you meant anyway...?)

> 
> 
>>2.4 Linux/CITI
>>
>>A Linux server sets ACE4_SYNCHRONIZE on all ALLOW ACEs.  Presumably it
>>accepts ACLs with ACE4_SYNCHRONIZE on ALLOW ACEs; what is the behavior
>>if it receives an ACL with ACE4_SYNCHRONIZE on a DENY ACE?
> 
> 
> It returns EINVAL.  It also returns EINVAL if you don't set
> SYNCHRONIZE in an ALLOW ace.  This should probably be relaxed; I can't
> see any harm to silently turning on SYNCHRONIZE in an ACL that didn't
> explicitly deny SYNCHRONIZE.

This is similar to our proposed changes.  The only subtle difference is 
that we wouldn't require ACE4_SYNCHRONIZE to be there in all cases (it 
can be completely missing), but we will return NFS4ERR_ATTRNOTSUPP if 
ACE4_SYNCHRONIZE is in a DENY ACE.

Might have to think about it a bit more, but I don't think we would mind 
requiring ACE4_SYNCHRONIZE to be on the ALLOW ACE's...I guess this would 
be the least suprising to the user.

> 
> 
>>3.1.1 Changes we could make to allow for better interoperability
>>
>>Server
>>
>>Solaris would set ACE4_WRITE_OWNER on all DENY ACEs it produces.  It
>>would also ignore ACE4_WRITE_OWNER on any DENY ACEs in any ACL it
>>receives, but would error with NFS4ERR_ATTRNOTSUPP if ACE4_WRITE_OWNER
>>is set on any ALLOW ACEs.
>>
> 
> ....
> 
>>3.4 Linux/CITI
>>
>>A Linux server sets ACE4_WRITE_OWNER on all DENY ACEs.  Presumably it
>>accepts ACLs with ACE4_WRITE_OWNER on DENY ACEs, and fails when
>>receiving ACLs with ACE4_WRITE_OWNER on ALLOW ACEs.
> 
> 
> Yes.  The Solaris behaviour sounds reasonable, though.

Just to clarify, which Solaris behavior sounds resonable.  The current 
or the proposed?

I think you meant the current behavior so:
We believe it would be a good goal to have our behaviors be the 
same...If you believe the current Solaris behavior is resonable, should 
we go with that?

> 
> 
>>4. ACE ordering on Solaris
>>
>>Solaris Beta 7 had a bug where NFSv4 ACLs were translated from
>>POSIX-draft incorrectly with regards to the ordering of the group
>>ACEs.
>>
>>This has been fixed as of November 22, 2004, and the fix will be
>>available in the final release of Solaris 10.
> 
> 
> Some reorderings of the group ACEs don't change the meaning of the ACE,
> and a smart implementation might allow for this.  But agreeing on an
> order allows a simpler implementation.

Yup.

> 
> Content-Description: Current Solaris behavior
> 
>>Current Solaris behavior is modeled after the internet draft
>>http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-acl-mapping-02.txt
>>by Marius Aamodt Eriksen and J. Bruce Fields.  There may be some changes
>>made before Solaris 10 is shipped, to allow for better interoperability
>>between Solaris and other vendors.
>>
>>This document describes what the Solaris NFSv4 Server will accept for
>>ACLs when it must map to POSIX-draft ACLs for a UFS filesystem.
> 
> 
> Thanks for the thorough description; I hope to take a closer look at it
> in the next couple days.  We also have a python script that tests some
> of the mapping behaviour.

Feel free to contact us with any questions (this goes to all of you)! 
The whole idea of that description is to get other vendors aware of what 
they have to do to interoperate with us.

We will continue to post updates to this doc with any future changes.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4