On 5/26/25 4: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.
I think the server should detect that the delegation stateid and the file
component do not belong to the same file and returns NFS4ERR_BAD_STATEID.
This will also prevent the subsequent access check problem.
-Dai
1.
2.
*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.
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>
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
