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

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?

> 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?

> 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.

> 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.

> 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.

> 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.

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.

--b.

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