public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: NeilBrown <neilb@suse.de>
Cc: "Pali Rohár" <pali@kernel.org>,
	"Jeff Layton" <jlayton@kernel.org>,
	"Olga Kornievskaia" <okorniev@redhat.com>,
	"Dai Ngo" <dai.ngo@oracle.com>, "Tom Talpey" <tom@talpey.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] nfsd: Fix NFSD_MAY_BYPASS_GSS and NFSD_MAY_BYPASS_GSS_ON_ROOT
Date: Wed, 9 Oct 2024 15:55:05 -0400	[thread overview]
Message-ID: <Zwbfmf3L5XphaiGs@tissot.1015granger.net> (raw)
In-Reply-To: <172842407597.3184596.2141619392088505446@noble.neil.brown.name>

On Tue, Oct 08, 2024 at 05:47:55PM -0400, NeilBrown wrote:
> And NFSD_MAY_LOCK should be discarded, and nlm_fopen() should set
> NFSD_MAY_BYPASS_SEC.

366         /*                                                                      
367          * pseudoflavor restrictions are not enforced on NLM,                   

Wrt the mention of "NLM", nfsd4_lock() also sets NFSD_MAY_LOCK.

368          * which clients virtually always use auth_sys for,                     
369          * even while using RPCSEC_GSS for NFS.                                 
370          */                                                                     
371         if (access & NFSD_MAY_LOCK)                                             
372                 goto skip_pseudoflavor_check;                                   
373         if (access & NFSD_MAY_BYPASS_GSS)                                       
374                 may_bypass_gss = true;
375         /*                                                                      
376          * Clients may expect to be able to use auth_sys during mount,          
377          * even if they use gss for everything else; see section 2.3.2          
378          * of rfc 2623.                                                         
379          */                                                                     
380         if (access & NFSD_MAY_BYPASS_GSS_ON_ROOT                                
381                         && exp->ex_path.dentry == dentry)                       
382                 may_bypass_gss = true;                                          
383                                                                                 
384         error = check_nfsd_access(exp, rqstp, may_bypass_gss);                  
385         if (error)                                                              
386                 goto out;                                                       
387                                                                                 
388 skip_pseudoflavor_check:                                                        
389         /* Finally, check access permissions. */                                
390         error = nfsd_permission(cred, exp, dentry, access);     

MAY_LOCK is checked in nfsd_permission() and __fh_verify().

But MAY_BYPASS_GSS is set in loads of places that use those two
functions. How can we be certain that the two flags are equivalent? 

Though I agree, simplifying this hot path would both help
performance scalability and reduce reader headaches. It might be a
little nicer to pass the NFSD_MAY flags directly to
check_nfsd_access(), for example.


-- 
Chuck Lever

  reply	other threads:[~2024-10-09 19:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-12 22:19 [PATCH] nfsd: Fix NFSD_MAY_BYPASS_GSS and NFSD_MAY_BYPASS_GSS_ON_ROOT Pali Rohár
2024-09-12 22:52 ` NeilBrown
2024-09-12 23:00   ` Pali Rohár
2024-10-06 17:50   ` Chuck Lever
2024-10-06 22:13     ` NeilBrown
2024-10-06 22:29       ` Pali Rohár
2024-10-06 22:58         ` Chuck Lever III
2024-10-06 23:36           ` NeilBrown
2024-10-07 15:50             ` Chuck Lever III
2024-10-08  1:17               ` Rick Macklem
2024-10-08 18:54       ` Pali Rohár
2024-10-08 18:57       ` Chuck Lever
2024-10-08 21:47         ` NeilBrown
2024-10-09 19:55           ` Chuck Lever [this message]
2024-10-09 20:14             ` NeilBrown
2024-10-09 23:30               ` Chuck Lever
2024-10-10 20:49                 ` NeilBrown
2024-10-05 16:40 ` [PATCH v2] " Pali Rohár
2024-10-09 18:41   ` cel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zwbfmf3L5XphaiGs@tissot.1015granger.net \
    --to=chuck.lever@oracle.com \
    --cc=dai.ngo@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=okorniev@redhat.com \
    --cc=pali@kernel.org \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox