On Thu, Jan 2, 2025 at 8:01 AM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On 1/2/25 8:41 AM, Jeff Layton 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. > > Another way to put it is the write delegation is equivalent to a RW > open. It permits the client to handle opens on this file locally without > having to send another OPEN on the wire (as long as certain conditions > hold true). > > So, therefore, the client is permitted to use that write delegation > state ID for READ operations. > > > > 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. > > > > > >> 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. > > > > 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. > > NFSD currently doesn't return this ACE, so the ACCESS round trip is > still needed. > > Basically the ACE tells the client what set of local open(2) calls > are allowed without having to return the write delegation. Yes, but I am not sure why you say "return the write delegation". I do not think that has anything to do with the ACE. The client must return the delegation when a CBRECALL is issued to it by the server. Otherwise, the client can DELEGRETURN whenever it feels like it. (Doing so when doing a REMOVE or RENAME can avoid a CBRECALL.) My interpretation is that the ACE tells the client when it can do local opens without bothering to do an ACCESS operation. rick > > > -- > Chuck Lever >
