Re: [PATCH v2] nfsd: refine and rename NFSD_MAY_LOCK

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 13 Mar 2025, Olga Kornievskaia wrote:
> On Wed, Mar 12, 2025 at 6:27 PM NeilBrown <neilb@xxxxxxx> wrote:
> >
> > On Thu, 13 Mar 2025, Olga Kornievskaia wrote:
> > > On Tue, Mar 11, 2025 at 5:42 PM NeilBrown <neilb@xxxxxxx> wrote:
> > > >
> > > > On Wed, 12 Mar 2025, Olga Kornievskaia wrote:
> > > > > On Tue, Mar 11, 2025 at 11:28 AM Olga Kornievskaia <aglo@xxxxxxxxx> wrote:
> > > > > >
> > > > > > On Thu, Oct 17, 2024 at 5:42 PM NeilBrown <neilb@xxxxxxx> wrote:
> > > > > > >
> > > > > > >
> > > > > > > NFSD_MAY_LOCK means a few different things.
> > > > > > > - it means that GSS is not required.
> > > > > > > - it means that with NFSEXP_NOAUTHNLM, authentication is not required
> > > > > > > - it means that OWNER_OVERRIDE is allowed.
> > > > > > >
> > > > > > > None of these are specific to locking, they are specific to the NLM
> > > > > > > protocol.
> > > > > > > So:
> > > > > > >  - rename to NFSD_MAY_NLM
> > > > > > >  - set NFSD_MAY_OWNER_OVERRIDE and NFSD_MAY_BYPASS_GSS in nlm_fopen()
> > > > > > >    so that NFSD_MAY_NLM doesn't need to imply these.
> > > > > > >  - move the test on NFSEXP_NOAUTHNLM out of nfsd_permission() and
> > > > > > >    into fh_verify where other special-case tests on the MAY flags
> > > > > > >    happen.  nfsd_permission() can be called from other places than
> > > > > > >    fh_verify(), but none of these will have NFSD_MAY_NLM.
> > > > > >
> > > > > > This patch breaks NLM when used in combination with TLS.
> > > > >
> > > > > I was too quick to link this to TLS. It's presence of security policy
> > > > > so sec=krb* causes the same problems.
> > > > >
> > > > > >  If exports
> > > > > > have xprtsec=tls:mtls and mount is done with tls/mtls, the server
> > > > > > won't give any locks and client will get "no locks available" error.
> > > > > >
> > > > > > >
> > > > > > > Signed-off-by: NeilBrown <neilb@xxxxxxx>
> > > > > > > ---
> > > > > > >
> > > > > > > No change from previous patch - the corruption in the email has been
> > > > > > > avoided (I hope).
> > > > > > >
> > > > > > >
> > > > > > >  fs/nfsd/lockd.c | 13 +++++++++++--
> > > > > > >  fs/nfsd/nfsfh.c | 12 ++++--------
> > > > > > >  fs/nfsd/trace.h |  2 +-
> > > > > > >  fs/nfsd/vfs.c   | 12 +-----------
> > > > > > >  fs/nfsd/vfs.h   |  2 +-
> > > > > > >  5 files changed, 18 insertions(+), 23 deletions(-)
> > > > > > >
> > > > > > > diff --git a/fs/nfsd/lockd.c b/fs/nfsd/lockd.c
> > > > > > > index 46a7f9b813e5..edc9f75dc75c 100644
> > > > > > > --- a/fs/nfsd/lockd.c
> > > > > > > +++ b/fs/nfsd/lockd.c
> > > > > > > @@ -38,11 +38,20 @@ nlm_fopen(struct svc_rqst *rqstp, struct nfs_fh *f, struct file **filp,
> > > > > > >         memcpy(&fh.fh_handle.fh_raw, f->data, f->size);
> > > > > > >         fh.fh_export = NULL;
> > > > > > >
> > > > > > > +       /*
> > > > > > > +        * Allow BYPASS_GSS as some client implementations use AUTH_SYS
> > > > > > > +        * for NLM even when GSS is used for NFS.
> > > > > > > +        * Allow OWNER_OVERRIDE as permission might have been changed
> > > > > > > +        * after the file was opened.
> > > > > > > +        * Pass MAY_NLM so that authentication can be completely bypassed
> > > > > > > +        * if NFSEXP_NOAUTHNLM is set.  Some older clients use AUTH_NULL
> > > > > > > +        * for NLM requests.
> > > > > > > +        */
> > > > > > >         access = (mode == O_WRONLY) ? NFSD_MAY_WRITE : NFSD_MAY_READ;
> > > > > > > -       access |= NFSD_MAY_LOCK;
> > > > > > > +       access |= NFSD_MAY_NLM | NFSD_MAY_OWNER_OVERRIDE | NFSD_MAY_BYPASS_GSS;
> > > > > > >         nfserr = nfsd_open(rqstp, &fh, S_IFREG, access, filp);
> > > > > > >         fh_put(&fh);
> > > > > > > -       /* We return nlm error codes as nlm doesn't know
> > > > > > > +       /* We return nlm error codes as nlm doesn't know
> > > > > > >          * about nfsd, but nfsd does know about nlm..
> > > > > > >          */
> > > > > > >         switch (nfserr) {
> > > > > > > diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> > > > > > > index 40533f7c7297..6a831cb242df 100644
> > > > > > > --- a/fs/nfsd/nfsfh.c
> > > > > > > +++ b/fs/nfsd/nfsfh.c
> > > > > > > @@ -363,13 +363,10 @@ __fh_verify(struct svc_rqst *rqstp,
> > > > > > >         if (error)
> > > > > > >                 goto out;
> > > > > > >
> > > > > > > -       /*
> > > > > > > -        * pseudoflavor restrictions are not enforced on NLM,
> > > > > > > -        * which clients virtually always use auth_sys for,
> > > > > > > -        * even while using RPCSEC_GSS for NFS.
> > > > > > > -        */
> > > > > > > -       if (access & NFSD_MAY_LOCK)
> > > > > > > -               goto skip_pseudoflavor_check;
> > > > > > > +       if ((access & NFSD_MAY_NLM) && (exp->ex_flags & NFSEXP_NOAUTHNLM))
> > > > >
> > > > > I think this should either be an OR or the fact that "nlm but only
> > > > > with insecurelock export option and not other" is the only way to
> > > > > bypass checking is wrong. I think it's just a check for NLM that
> > > > > stays.
> > > >
> > > > I don't think that NLM gets a complete bypass unless no_auth_nlm is set.
> > > > For the case you are describing, I think NFSD_MAY_BYPASS_GSS is supposed
> > > > to make it work.
> > > >
> > > > I assume the NLM request is arriving with AUTH_SYS authentication?
> > >
> > > It does.
> > >
> > > Just to give you a practical example. exports have
> > > (rw,...,sec=krb5:krb5i:krb5p). Client does mount with sec=krb5. Then
> > > does an flock() on the file. What's more I have just now hit Kasan's
> > > out-of-bounds warning on that. I'll have to see if that exists on 6.14
> > > (as I'm debugging the matter on the commit of the patch itself and
> > > thus on 6.12-rc now).
> > >
> > > I will layout more reasoning but what allowed NLM to work was this
> > > -       /*
> > > -        * pseudoflavor restrictions are not enforced on NLM,
> > > -        * which clients virtually always use auth_sys for,
> > > -        * even while using RPCSEC_GSS for NFS.
> > > -        */
> > > -       if (access & NFSD_MAY_LOCK)
> > > -               goto skip_pseudoflavor_check;
> > >
> > > but I don't know why the replacement doesn't work.
> >
> > Can you see if this fixes it?
> > Maybe we need to bypass tls as well as gss
> >
> > Thanks,
> > NeilBrown
> >
> > --- a/fs/nfsd/export.c
> > +++ b/fs/nfsd/export.c
> > @@ -1124,7 +1124,8 @@ __be32 check_nfsd_access(struct svc_export *exp, struct svc_rqst *rqstp,
> >                     test_bit(XPT_PEER_AUTH, &xprt->xpt_flags))
> >                         goto ok;
> >         }
> > -       goto denied;
> > +       if (!may_bypass_gss)
> > +               goto denied;
> >
> 
> I don't think this would help in any way as NLM does pass may_bypass_gss...

Yes, so for NLM it won't "goto denied" but will fall through and pass
the other checks.

NeilBrown


> 
> >  ok:
> >         /* legacy gss-only clients are always OK: */
> 






[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux