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

Sam.Falkner@Sun.COM

Date: Wed, 01 Dec 2004 13:34:00 -0700
From: Sam Falkner <Sam.Falkner@Sun.COM>
Message-id: <ii7y8ghpxl3.fsf@central.sun.com>
Subject: [nfsv4] NFSv4 <-> POSIX-draft ACL interoperability

The following is a summary of the issues found at the October Bakeathon. 

The issues stem from various vendor's need to translate to and from
NFSv4 and POSIX-draft ACL models.  Many of these points are being
re-iterated from an email thread started earlier by Bruce Fields.

We are also attaching a document that describes current Solaris server
behaviors.

- Sam Falkner
  Lisa Week

Building on the previous thread, in order to most correctly resolve
these issues there are a couple of different angles of the problems to
think about.

The issues can be divided up into client and server problems.
These being:

1.) What should a server accept upon a client setting an ACL.
2.) What should a server respond as being the base ACL on a file upon 
    its creation.
3.) What should a client accept upon getting an ACL.
4.) What should a client attempt to set.

Issues

0. Motivation for current Solaris behavior

In any situation where the existing Solaris filesystem (UFS) could not
enforce the semantics of an NFSv4 ACL, it was decided to reject the ACL,
rather than inaccurately representing the NFSv4 ACL on the server
filesystem.

We still feel that being strict with what ACLs are accepted is the most
correct approach, but we are considering making changes in order to
improve interoperability.

1. ACE4_DELETE

1.1 Solaris

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.

Rationale: with current Solaris filesystems, the ability to delete a
file cannot be allowed or denied on a per-file basis via an ACL.
Instead, this is determined via the permissions on the parent
directory.

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.

Client

Solaris client would continue to produce ACLs without ACE4_DELETE set
on any ACEs.  When the Solaris client receives an ACL, it would ignore
the ACE4_DELETE mask on any ACEs.  The drawback for this would be that
"setfacl -m ...", which is a command line utility to modify an existing
POSIX-draft ACL, would silently lose any ACE4_DELETE masks that were
present in the original ACL.

1.2 IBM

An AIX server requires that both ACE4_DELETE be ALLOWED on a file, and
ACE4_DELETE_CHILD be ALLOWED on the parent directory, in order to
delete a file.

1.3 NetApp

A NetApp server requires that either ACE4_DELETE be ALLOWED on a file,
or ACE4_DELETE_CHILD be ALLOWED on a directory, in order to delete a
file.

1.4 Linux/CITI

???

2. ACE4_SYNCHRONIZE

2.1 Solaris

Currently, Solaris does not set the ACE4_SYNCHRONIZE on any ACEs.  If a
Solaris client or server receives an ACL with ACE4_SYNCHRONIZE on any
ACEs, it fails; server returns NFS4ERR_ATTRNOTSUPP, client gives
ENOTSUP and it fabricates an ACL from the mode bits of the file.

Rationale: ACE4_SYNCHRONIZE has no meaning on a POSIX system.

2.1.1 Changes we could make to allow for better interoperability

Server

Solaris would set ACE4_SYNCHRONIZE on all ALLOW ACEs.  Server would
accept an ACL with ACE4_SYNCHRONIZE on any ALLOW ACEs, but return
NFS4ERR_ATTRNOTSUPP if ACE4_SYNCHRONIZE is on any DENY ACEs.

Client

Solaris client would ignore ACE4_SYNCHRONIZE on any ACEs upon getting
an ACL.  Client would set ACE4_SYNCHRONIZE on any ALLOW ACEs on setting
an ACL.

2.2 IBM

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

2.3 NetApp

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

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?

3. ACE4_WRITE_OWNER

3.1 Solaris

Currently, a Solaris server does not set ACE4_WRITE_OWNER on any ACEs.
If it receives an ACL with ACE4_WRITE_OWNER on any ACEs, it will return
NFS4ERR_ATTRNOTSUPP.  If a Solaris client receives an ACL with
ACE4_WRITE_OWNER set on any ACEs, it will fail with ENOTSUP and may
fabricate an ACL based on the file's mode bits.

Rationale: with the current Solaris filesystems, the ability to write
the owner (i.e. "chown") cannot be allowed or denied on a per-file
basis via an ACL.

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.

Client

Solaris would ignore ACE4_WRITE_OWNER on any ACEs in any ACL it
receives.  It would continue its policy of never setting
ACE4_WRITE_OWNER on any ACEs in ACLs that it produces.  The drawback
for this would be that "setfacl -m ...", which is a command line
utility to modify an existing POSIX-draft ACL, would silently lose any
ACE4_WRITE_OWNER masks that were present in the original ACL.

3.2 IBM

???

3.3 NetApp

???

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.

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.