Message-ID: <3B6E6840-4D54-45AC-A482-C76D63E8BFB9@oracle.com>
Date: Sat, 5 Oct 2024 15:40:15 +0000
From: Chuck Lever III <chuck.lever@...cle.com>
To: Pali Rohár <pali@...nel.org>
CC: Jeff Layton <jlayton@...nel.org>, Neil Brown <neilb@...e.de>,
        Olga
 Kornievskaia <okorniev@...hat.com>, Dai Ngo <dai.ngo@...cle.com>,
        Tom Talpey
	<tom@...pey.com>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] nfsd: Add support for mapping sticky bit into NFS4 ACL



> On Oct 5, 2024, at 11:08 AM, Pali Rohár <pali@...nel.org> wrote:
> 
> Hello Chuck, have you done more research on this as mentioned?

My position has not changed from the last email I sent:

> The fundamental claim from your patch description is that:
> 
>>>> the NFS4 ACL client is not
>>>> aware of the fact that it cannot delete some files if the
>>>> sticky bit is set on the server on parent directory.
> 
> POSIX-based clients are in fact aware of this additional constraint
> because they can see the set of mode bits returned by GETATTR.
> 
> So can non-POSIX clients for that matter; although they might not
> natively understand what that bit means, their NFS client can impart
> that meaning.
> 
> I can find no spec mandate or guidance that requires this mapping,
> nor can I find any other NFS server implementations that add it.
> If this is indeed a valuable innovation, a standard that recommends
> or requires implementation of this feature would be the place to
> begin.
> 
> What RFC 8881 does say is on point:
> 
>> 6.3.1.1. Server Considerations
> 
>> The server uses the algorithm described in Section 6.2.1 to
>> determine whether an ACL allows access to an object. However, the
>> ACL might not be the sole determiner of access.
> 
> A list of examples follows. The spirit of this text seems to be that
> a file object's ACL need not reflect every possible security policy
> that a server might use to determine whether an operation may
> proceed.

Which is to say that I need you to approach the nfsv4 WG with
this proposal first before it can be considered for NFSD.

After all, if this is a good thing for NFS servers to do, why
wouldn't you want to get other NFS server vendors to implement
this as well?

Meanwhile you are free to carry this patch in your own fork
so that others can experiment.


> I think that this is really useful for non-POSIX clients as NFS4 ACLs
> are not-POSIX; knfsd is already translating POSIX ACLs to non-POSIX
> NFS4 ACLs, and this is just an improvement to covert also the
> POSIX-sticky-bit in non-POSIX NFS4 ACL.
> 
> Also another improvement is that this change allows to modify all parts
> of POSIX access mode (sticky bit, base mode permissions r/w/x and POSIX
> ACL) via NFS4 ACL structure. So non-POSIX NFS4 client would be able to
> add or remove directory sticky bit via NFS4 ACL editor.

A real-world use case would be helpful for making the case
that this is something we want NFS servers to do. Currently
this is a "wouldn't it be nice if..." and I don't hear any
users saying "I can use this feature today if it existed".

But as I said above: non-POSIX clients can retrieve file
attributes and file ACLs in the same COMPOUND. If the client
sees the sticky bit, it can manufacture the extra ACEs itself
before presenting the ACL to local applications. There is
really no technical need for NFS servers to do this that I
can see.

TL;DR:

1. The ACEs can be added by clients themselves (and really
that is the preferred approach since the vast majority of
NFS client implementations don't need this behavior).

2. There has been no architectural review of the proposal.

3. There is no user demand for it that I am aware of.


--
Chuck Lever

Powered by blists - more mailing lists