On Mon, 2025-05-26 at 14:10 +0300, 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.
> Please see the attached PCAP file for reference.
> Best regards,
> Petro Pavlov
>
Yeah, that does seem like a bug. Mostly, the server treats
CLAIM_DELEGATE_CUR and CLAIM_NULL identically. We have this in
do_open_lookup() though:
if (open->op_created ||
open->op_claim_type == NFS4_OPEN_CLAIM_DELEGATE_CUR)
accmode |= NFSD_MAY_OWNER_OVERRIDE;
status = do_open_permission(rqstp, *resfh, open, accmode);
set_change_info(&open->op_cinfo, current_fh);
...and that effectively bypasses the permission check in this case.
Maybe we should add a fh check there?
I'm not sure why CLAIM_DELEGATE_CUR wasn't deprecated when
CLAIM_DELEGATE_CUR_FH was added to the spec. Is there some use case
where CUR is necessary instead of CUR_FH?
> 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
> >
> >
--
Jeff Layton <jlayton@xxxxxxxxxx>
