Re: GSSAPI as it relates to NFS

["bfields@fieldses.org" <bfields@fieldses.org>]

On Mon, Jan 03, 2022 at 09:45:45PM +0000, Trond Myklebust wrote:
> On Mon, 2022-01-03 at 16:32 -0500, J. Bruce Fields wrote:
> > On Sat, Dec 25, 2021 at 10:53:33PM +0000, Chuck Lever III wrote:
> > > IIRC Linux requires that a mount operation be done by root. If you
> > > run
> > > gssd with "-n", become root, then kinit as yourself, I think it
> > > should
> > > work.
> > > 
> > > There has been some discussion about enabling a non-privileged user
> > > to
> > > perform a mount... it's a bit tricky because the function of mount
> > > is
> > > to alter the file namespace, which traditionally requires extra
> > > privilege to do.
> > 
> > The core VFS code is quite happy to allow you to make unprivileged
> > mounts in your own namespace, but the particular filesystem being
> > mounted also gets a veto.
> > 
> > I think we're expecting NFS will be patched to allow unprivileged
> > mounts
> > some time.  See e.g.
> > 
> >         
> > https://lore.kernel.org/linux-nfs/aec219339d8296b7e9b114d9d247a71fd47423c5.camel@hammerspace.com
> > /
> > 
> > --b.
> 
> As noted, the main issue is the bind() privileges needed for AUTH_SYS. 
> 
> When using AUTH_GSS, the knfsd server doesn't care about the
> originating port, which would allow unprivileged mounts to go ahead
> provided that the user specifies the 'noresvport' mount option on the
> client. Isn't that working?

Oh, I remembered you'd said that was one of the issues, but didn't
understand that that was literally the only check remaining in the
code....  In which case, you could also test this by using setcap on
/usr/bin/mount or capsh to give the mount process CAP_NET_BIND_SERVICE?
(If you also set up the right namespaces first.)

--b.