[nfsv4] RFC: atomically acquiring some attributes for the posix-acls extension

[Rick Macklem <[e-mail]>]

Hi,

As some will already know, I am working on a draft that
proposes an extension to 4.2 related to POSIX ACLs which
adds 4 new attributes.

I have run into a case where specifying the GETATTR return
some ACL related attributes "atomically". By atomically, I
mean that no SETATTR by another client is permitted to change
any on the attributes during the GETATTR.

Some background:
true form - Is the kind of ACL stored on the file object and
            used for access permissions. A new attribute called
            acl_trueform indicates what the true form is.
            It can be ACL_MODEL_NFS4, ACL_MODEL_POSIX_DRAFT or
            ACL_MODEL_NONE.
posix_access_acl, posix_default_acl - New attributes for the POSIX
            access and default ACLs.

Now, assume a file system on a server supports all of the
acl, posix_access_acl, posix_default_acl and acl_trueform
attributes.

If a client does a:
GETATTR of acl, posix_access_acl, posix_default_acl and acl_trueform.
If this GETATTR is guaranteed to be "atomic" (as in no SETATTR is allowed
to change any of these attributes), then the reply gives the client
exactly what it needs.
--> The acl_trueform tells the client whether the acl attribute or
    posix_access_acl/posix_default_acl attributes are what is actually
    being stored for the file object and used for permission checking.

However, without the atomicity guarantee, a SETATTR of acl/posix_access_acl/
posix_default_acl done by another client could "gum up the works" and
result in a weird/inconsistent reply.

So, it requiring this atomicity guarantee for these attributes a
reasonable thing for the extension, if the server chooses to support
the extension?

Now, for SETATTR, it would be nice if a client could set a POSIX ACL,
but only if no NFSv4 ACL is already stored on the file object.
The following compound could "almost" do this:
    NVERIFY acl_trueform ACL_MODEL_NFS4
    SETATTR posix_access_acl
The "almost" is because there is no atomicity guarantee for operations
in compounds, but that will be my next email.

Thanks in advance for any opinions w.r.t. the GETATTR atomicity guarantee,
rick