> On Oct 5, 2024, at 11:08 AM, Pali Rohár <pali@xxxxxxxxxx> 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
