On Thu, Jan 2, 2025 at 5:41 AM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Thu, 2025-01-02 at 11:08 +0200, Shaul Tamari wrote: > > Hi, > > > > I have a question regarding NFS4.1 write delegation stateid permission checks. > > > > Is there a difference in how a server should check permissions for a > > write delegation stateid that was given when the file was opened with: > > 1. OPEN4_SHARE_ACCESS_BOTH > > 2. OPEN4_SHARE_ACCESS_WRITE > > > > (cc'ing Sagi since he was looking at this recently) > > A write delegation really should have been called a read-write > delegation, because the server has to allow the client to do reads as > well, if you hold one. My interpretation for "write" is that it was a synonym for "exclusive". > > The Linux kernel nfs server doesn't currently give out delegations to > OPEN4_SHARE_ACCESS_WRITE-only opens for this reason. You have to > request BOTH in order to get one, because a permission check for write > is not sufficient to allow you to read as well. I'll admit my interpretation has always been somewhat different. My version is that a delegation allows a client to do Opens locally, but does not infer permissions for any given user. A Jeff notes at the end of his post, a client must do a ACCESS operation to check for permissions during Opens unless the ACE in the write delegation reply allows access. Given the above, a server's decision to issue a write delegation is orthogonal to file permissions, except for what it returns in the ACE, imho. > > > > Should the server check permissions for read access as well when > > OPEN4_SHARE_ACCESS_WRITE is requested and DELEGATION_WRITE is granted > > ? > > > > Possibly? When trying to grant a write delegation, the server should > probably also do an opportunistic permission check for read as well, > and only grant the delegation if that passes. If it fails, you could > still allow the open and just not grant the delegation. My interpretation is that the server can choose to (or choose not to) issue a delegation for any file. The only requirement is a working callback path. The WANT_xxx flags are just hints from the client. Although it might not make much sense, a server can even issue a write delegation for a file that is r--r--r--. Again, this is my interpretation of the RFCs. > > ISTR that Sagi may have tried this approach though and there was a > problem with it? > > > or there is an assumption that the client will query the server for > > read access permissions ? > > > > The client should always do an ACCESS call to test permissions unless > the user's access matches the ACE that gets sent along with the > delegation. Yes, and this is why a write delegation can be issued whenever the server feels like doing so. rick > -- > Jeff Layton <jlayton@xxxxxxxxxx> >
