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

[David Noveck <[e-mail]>]

On Thu, Aug 8, 2024, 4:15 PM Rick Macklem <[e-mail]> wrote:

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

Yes.


> 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
>
>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>