linux-ext4 - Re: [PATCH v6 05/39] namei: make permission helpers idmapped mount aware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210124224450.3dtdgvwxpdf5niuz@wittgenstein>
Date:   Sun, 24 Jan 2021 23:44:50 +0100
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     "J. Bruce Fields" <bfields@...ldses.org>
Cc:     Alexander Viro <viro@...iv.linux.org.uk>,
        Christoph Hellwig <hch@....de>, linux-fsdevel@...r.kernel.org,
        John Johansen <john.johansen@...onical.com>,
        James Morris <jmorris@...ei.org>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Arnd Bergmann <arnd@...db.de>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
        Geoffrey Thomas <geofft@...reload.com>,
        Mrunal Patel <mpatel@...hat.com>,
        Josh Triplett <josh@...htriplett.org>,
        Andy Lutomirski <luto@...nel.org>,
        Theodore Tso <tytso@....edu>, Alban Crequy <alban@...volk.io>,
        Tycho Andersen <tycho@...ho.ws>,
        David Howells <dhowells@...hat.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Seth Forshee <seth.forshee@...onical.com>,
        Stéphane Graber <stgraber@...ntu.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Aleksa Sarai <cyphar@...har.com>,
        Lennart Poettering <lennart@...ttering.net>,
        "Eric W. Biederman" <ebiederm@...ssion.com>, smbarber@...omium.org,
        Phil Estes <estesp@...il.com>, Serge Hallyn <serge@...lyn.com>,
        Kees Cook <keescook@...omium.org>,
        Todd Kjos <tkjos@...gle.com>, Paul Moore <paul@...l-moore.com>,
        Jonathan Corbet <corbet@....net>,
        containers@...ts.linux-foundation.org,
        linux-security-module@...r.kernel.org, linux-api@...r.kernel.org,
        linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org,
        linux-integrity@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH v6 05/39] namei: make permission helpers idmapped mount
 aware

On Sun, Jan 24, 2021 at 05:18:54PM -0500, J. Bruce Fields wrote:
> On Sat, Jan 23, 2021 at 02:09:58PM +0100, Christian Brauner wrote:
> > On Fri, Jan 22, 2021 at 05:26:32PM -0500, J. Bruce Fields wrote:
> > > If I NFS-exported an idmapped mount, I think I'd expect idmapped clients
> > > to see the mapped IDs.
> > > 
> > > Looks like that means taking the user namespace from the struct
> > > svc_export everwhere, for example:
> > > 
> > > On Thu, Jan 21, 2021 at 02:19:24PM +0100, Christian Brauner wrote:
> > > > index 66f2ef67792a..8d90796e236a 100644
> > > > --- a/fs/nfsd/nfsfh.c
> > > > +++ b/fs/nfsd/nfsfh.c
> > > > @@ -40,7 +40,8 @@ static int nfsd_acceptable(void *expv, struct dentry *dentry)
> > > >  		/* make sure parents give x permission to user */
> > > >  		int err;
> > > >  		parent = dget_parent(tdentry);
> > > > -		err = inode_permission(d_inode(parent), MAY_EXEC);
> > > > +		err = inode_permission(&init_user_ns,
> > > > +				       d_inode(parent), MAY_EXEC);
> > > 
> > > 		err = inode_permission(exp->ex_path.mnt->mnt_userns,
> > > 				      d_inode(parent, MAY_EXEC);
> > 
> > Hey Bruce, thanks! Imho, the clean approach for now is to not export
> > idmapped mounts until we have ported that part of nfs similar to what we
> > do for stacking filesystems for now. I've tested and taken this patch
> > into my tree:
> 
> Oh good, thanks.  My real fear was that we'd fix this up later and leave
> users in a situation where the server exposes different IDs depending on
> kernel version, which would be a mess.  Looks like this should avoid
> that.
> 
> As for making idmapped mounts actually work with nfsd--are you planning
> to do that, or do you need me to?  I hope the patch is straightforward;

I'm happy to do it or help and there's other people I know who are also
interested in that and would likely be happy to do the work too.

> I'm more worried testing it.

This whole series has a large xfstest patch associated with it that
tests regular vfs behavior and vfs behavior with idmapped mounts. Iirc,
xfstests also has infrastructure to test nfs. So I'd expect we expand
the idmapped mounts testsuite to test nfs behavior as well.
So far it has proven pretty helpful and has already unconvered an
unrelated setgid-inheritance xfs bug that Christoph fixed a short time
ago.