On Monday 07 October 2024 09:13:17 NeilBrown wrote: > On Mon, 07 Oct 2024, Chuck Lever wrote: > > On Fri, Sep 13, 2024 at 08:52:20AM +1000, NeilBrown wrote: > > > On Fri, 13 Sep 2024, Pali Rohár wrote: > > > > Currently NFSD_MAY_BYPASS_GSS and NFSD_MAY_BYPASS_GSS_ON_ROOT do not bypass > > > > only GSS, but bypass any authentication method. This is problem specially > > > > for NFS3 AUTH_NULL-only exports. > > > > > > > > The purpose of NFSD_MAY_BYPASS_GSS_ON_ROOT is described in RFC 2623, > > > > section 2.3.2, to allow mounting NFS2/3 GSS-only export without > > > > authentication. So few procedures which do not expose security risk used > > > > during mount time can be called also with AUTH_NONE or AUTH_SYS, to allow > > > > client mount operation to finish successfully. > > > > > > > > The problem with current implementation is that for AUTH_NULL-only exports, > > > > the NFSD_MAY_BYPASS_GSS_ON_ROOT is active also for NFS3 AUTH_UNIX mount > > > > attempts which confuse NFS3 clients, and make them think that AUTH_UNIX is > > > > enabled and is working. Linux NFS3 client never switches from AUTH_UNIX to > > > > AUTH_NONE on active mount, which makes the mount inaccessible. > > > > > > > > Fix the NFSD_MAY_BYPASS_GSS and NFSD_MAY_BYPASS_GSS_ON_ROOT implementation > > > > and really allow to bypass only exports which have some GSS auth flavor > > > > enabled. > > > > > > > > The result would be: For AUTH_NULL-only export if client attempts to do > > > > mount with AUTH_UNIX flavor then it will receive access errors, which > > > > instruct client that AUTH_UNIX flavor is not usable and will either try > > > > other auth flavor (AUTH_NULL if enabled) or fails mount procedure. > > > > > > > > This should fix problems with AUTH_NULL-only or AUTH_UNIX-only exports if > > > > client attempts to mount it with other auth flavor (e.g. with AUTH_NULL for > > > > AUTH_UNIX-only export, or with AUTH_UNIX for AUTH_NULL-only export). > > > > > > The MAY_BYPASS_GSS flag currently also bypasses TLS restrictions. With > > > your change it doesn't. I don't think we want to make that change. > > > > Neil, I'm not seeing this, I must be missing something. > > > > RPC_AUTH_TLS is used only on NULL procedures. > > > > The export's xprtsec= setting determines whether a TLS session must > > be present to access the files on the export. If the TLS session > > meets the xprtsec= policy, then the normal user authentication > > settings apply. In other words, I don't think execution gets close > > to check_nfsd_access() unless the xprtsec policy setting is met. > > check_nfsd_access() is literally the ONLY place that ->ex_xprtsec_modes > is tested and that seems to be where xprtsec= export settings are stored. > > > > > I'm not convinced check_nfsd_access() needs to care about > > RPC_AUTH_TLS. Can you expand a little on your concern? > > Probably it doesn't care about RPC_AUTH_TLS which as you say is only > used on NULL procedures when setting up the TLS connection. > > But it *does* care about NFS_XPRTSEC_MTLS etc. > > But I now see that RPC_AUTH_TLS is never reported by OP_SECINFO as an > acceptable flavour, so the client cannot dynamically determine that TLS > is required. So there is no value in giving non-tls clients access to > xprtsec=mtls exports so they can discover that for themselves. The > client needs to explicitly mount with tls, or possibly the client can > opportunistically try TLS in every case, and call back. > > So the original patch is OK. So if the original patch is also OK, you can choose which one you like more. Original V1 restrict bypass to only GSS. V2 allows bypass for any non-null/unix methods. Let me know if something more is needed for this change.
