On 5/26/25 7:10 AM, Petro Pavlov wrote: > Hello Chuck, > > Thank you for your response, and apologies for the confusion regarding > the kernel version — the correct version is 6.15.0-rc3+ (I believe it's > from the branch you gave us). Regarding the client, I'm using hand- > written tests based on pynfs. > > I believe the following section of the RFC may be relevant to the use of > a delegation |stateid| in relation to the file being accessed: > > If the stateid type is not valid for the context in which the > stateid appears, return NFS4ERR_BAD_STATEID. Note that a stateid may > be valid in general, as would be reported by the TEST_STATEID > operation, but be invalid for a particular operation, as, for > example, when a stateid that doesn't represent byte-range locks is > passed to the non-from_open case of LOCK or to LOCKU, or when a > stateid that does not represent an open is passed to CLOSE or > OPEN_DOWNGRADE. In such cases, the server MUST return > NFS4ERR_BAD_STATEID. > > > I did some further investigation and identified another scenario that > seems problematic: > > 1. > > *Client1* creates |file1| without a delegation, with read-write > access. It writes some data, changes the file mode to |444|, and > then closes the file. > > 2. > > *Client2* opens |file1| with read access, receives a read delegation > (|deleg1|), and closes the file without returning the delegation. > > 3. > > *Client2* then creates |file2| with read-write access, receives a > write delegation (|deleg2|), and leaves the file open (delegation is > not returned). > > 4. > > *Client2* tries to open |file1| with write access and receives an | > ACCESS_DENIED| error (expected). > > 5. > > Next, *Client2* attempts to open |file1| with *write *access using > CLAIM_DELEGATE_CUR, providing the stateid from deleg2 (which was > issued for |file2|) — unexpectedly, the operation succeeds. > > 6. > > *Client2* proceeds to write to |file1|, and it also succeeds — > despite the file being set to |444|, where no write access should be > allowed. > > This behavior seems incorrect, as I would expect the write operation to > fail due to file permissions. This is a server bug, since the permissions on file1 prohibit writes to the file. > Please see the attached PCAP file for reference. > > Best regards, > Petro Pavlov > > > On Fri, May 23, 2025 at 5:41 PM Chuck Lever <chuck.lever@xxxxxxxxxx > <mailto:chuck.lever@xxxxxxxxxx>> wrote: > > On 5/22/25 11:51 AM, Petro Pavlov wrote: > > Hello, > > > > My name is Petro Pavlov, I'm a developer at VAST. > > > > I have a few questions about the delegation claim behavior observed in > > the Linux kernel version 3.10.0-1160.118.1.el7.x86_64. > > > > I’ve written the following test case: > > > > 1. Client1 opens *file1* with a write delegation; the server grants > > both the open and delegation (*delegation1*). > > Since you mention a write delegation, I'll assume you are using Linux > as an NFS client, and the server is not Linux, since that kernel version > does not implement server-side write delegation. > > > > 2. Client1 closes the open but does not return the delegation. > > 3. Client2 opens *file2* and also receives a write delegation > > (*delegation2*). > > 4. Client1 then issues an open request with CLAIM_DELEGATE_CUR, > > providing the filename from step 3 *(file2*), but using the > > delegation stateid from step 1 (*delegation1*). > > Would that be a client bug? > > > > 5. The server begins a recall of *delegation2*, treating the > request in > > step 4 as a normal open rather than returning a BAD_STATEID error. > > That seems OK to me. The server has correctly noticed that the > client is opening file2, and delegation2 is associated with a > previous open of file2. > > A better place to seek an authoritative answer might be RFC 8881. > > The server returns BAD_STATEID if the stateid doesn't pass various > checks as outlined in Section 8.2. I don't see any text requiring the > server to report BAD_STATEID if delegate_stateid does not match the > component4 on a DELEGATE_CUR OPEN -- in fact, Table 19 says that > DELEGATE_CUR considers only the current file handle (the parent > directory) and the component4 argument. > > > > My understanding is that the server should have verified whether the > > delegation stateid provided actually belongs to the file being opened. > > Since it does not, I expected the server to return a BAD_STATEID error > > instead of proceeding with a standard open. > > > > From additional tests, it seems the server only checks whether the > > delegation stateid is valid (i.e., whether it was ever granted), but > > does not verify that it is associated with the correct file or client. > > Please see the attached PCAP for reference. > > > > Questions: > > > > Is this behavior considered a bug? > > > > Are there any known plans to address or fix this issue in future > kernel > > versions? > > AFAICT at the moment, NOTABUG > > > -- > Chuck Lever > -- Chuck Lever
