linux-ext4 - Re: [PATCH v5 00/42] idmapped mounts

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 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]

Date:   Fri, 15 Jan 2021 12:51:20 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Dave Chinner <david@...morbit.com>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        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>,
        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 v5 00/42] idmapped mounts

On Fri, Jan 15, 2021 at 04:24:23PM +0000, Christoph Hellwig wrote:
> 
> That is what the capabilities are designed for and we already check
> for them.

So perhaps I'm confused, but my understanding is that in the
containers world, capabilities are a lot more complicated.  There is:

1) The initial namespace capability set

2) The container's user-namespace capability set

3) The namespace in which the file system is mounted --- which is
      "usually, but not necessarily the initial namespace" and
      presumably could potentially not necessarily be the current
      container's user name space, is namespaces can be hierarchically
      arranged.

Is that correct?  If so, how does this patch set change things (if
any), and and how does this interact with quota administration
operations?

On a related note, ext4 specifies a "reserved user" or "reserved
group" which can access the reserved blocks.  If we have a file system
which is mounted in a namespace running a container which is running
RHEL or SLES, and in that container, we have a file system mounted (so
it was not mounted in the initial namespace), with id-mapping --- and
then there is a further sub-container created with its own user
sub-namespace further mapping uids/gids --- will the right thing
happen?  For that matter, how *is* the "right thing" defined?

Sorry if this is a potentially stupid question, but I find user
namespaces and id and capability mapping to be hopefully confusing for
my tiny brain.  :-)

						- Ted