From: "Theodore Ts'o" <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: Dave Chinner <david@fromorbit.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Christian Brauner <christian.brauner@ubuntu.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org,
John Johansen <john.johansen@canonical.com>,
James Morris <jmorris@namei.org>,
Mimi Zohar <zohar@linux.ibm.com>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
Stephen Smalley <stephen.smalley.work@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Arnd Bergmann <arnd@arndb.de>,
Andreas Dilger <adilger.kernel@dilger.ca>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
Geoffrey Thomas <geofft@ldpreload.com>,
Mrunal Patel <mpatel@redhat.com>,
Josh Triplett <josh@joshtriplett.org>,
Andy Lutomirski <luto@kernel.org>,
Alban Crequy <alban@kinvolk.io>, Tycho Andersen <tycho@tycho.ws>,
David Howells <dhowells@redhat.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Seth Forshee <seth.forshee@canonical.com>,
St?phane Graber <stgraber@ubuntu.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Aleksa Sarai <cyphar@cyphar.com>,
Lennart Poettering <lennart@poettering.net>,
"Eric W. Biederman" <ebiederm@xmission.com>,
smbarber@chromium.org, Phil Estes <estesp@gmail.com>,
Serge Hallyn <serge@hallyn.com>,
Kees Cook <keescook@chromium.org>, Todd Kjos <tkjos@google.com>,
Paul Moore <paul@paul-moore.com>,
Jonathan Corbet <corbet@lwn.net>,
containers@lists.linux-foundation.org,
linux-security-module@vger.kernel.org, linux-api@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-integrity@vger.kernel.org, selinux@vger.kernel.org
Subject: Re: [PATCH v5 00/42] idmapped mounts
Date: Fri, 15 Jan 2021 12:51:20 -0500 [thread overview]
Message-ID: <YAHWGMb9rTehRsRz@mit.edu> (raw)
In-Reply-To: <20210115162423.GB2179337@infradead.org>
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
next prev parent reply other threads:[~2021-01-15 17:53 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-12 22:00 [PATCH v5 00/42] idmapped mounts Christian Brauner
2021-01-12 22:00 ` [PATCH v5 01/42] namespace: take lock_mount_hash() directly when changing flags Christian Brauner
2021-01-12 22:00 ` [PATCH v5 02/42] mount: make {lock,unlock}_mount_hash() static Christian Brauner
2021-01-12 22:00 ` [PATCH v5 03/42] namespace: only take read lock in do_reconfigure_mnt() Christian Brauner
2021-01-12 22:00 ` [PATCH v5 04/42] fs: split out functions to hold writers Christian Brauner
2021-01-12 22:00 ` [PATCH v5 05/42] fs: add attr_flags_to_mnt_flags helper Christian Brauner
2021-01-12 22:00 ` [PATCH v5 06/42] fs: add mount_setattr() Christian Brauner
2021-01-12 22:00 ` [PATCH v5 07/42] tests: add mount_setattr() selftests Christian Brauner
2021-01-12 22:00 ` [PATCH v5 08/42] fs: add id translation helpers Christian Brauner
2021-01-12 22:00 ` [PATCH v5 09/42] mount: attach mappings to mounts Christian Brauner
2021-01-19 9:20 ` Christoph Hellwig
2021-01-12 22:00 ` [PATCH v5 10/42] capability: handle idmapped mounts Christian Brauner
2021-01-19 9:22 ` Christoph Hellwig
2021-01-12 22:00 ` [PATCH v5 11/42] namei: make permission helpers idmapped mount aware Christian Brauner
2021-01-19 9:23 ` Christoph Hellwig
2021-01-12 22:00 ` [PATCH v5 12/42] inode: make init and " Christian Brauner
2021-01-19 9:24 ` Christoph Hellwig
2021-01-12 22:00 ` [PATCH v5 13/42] attr: handle idmapped mounts Christian Brauner
2021-01-19 9:25 ` Christoph Hellwig
2021-01-12 22:00 ` [PATCH v5 14/42] acl: " Christian Brauner
2021-01-19 9:26 ` Christoph Hellwig
2021-01-12 22:00 ` [PATCH v5 15/42] fs: add file_user_ns() helper Christian Brauner
2021-01-19 9:27 ` Christoph Hellwig
2021-01-19 15:05 ` Jann Horn
2021-01-20 12:03 ` Christian Brauner
2021-01-12 22:00 ` [PATCH v5 16/42] xattr: handle idmapped mounts Christian Brauner
2021-01-19 9:31 ` Christoph Hellwig
2021-01-12 22:00 ` [PATCH v5 17/42] commoncap: " Christian Brauner
2021-01-19 9:31 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 18/42] stat: " Christian Brauner
2021-01-19 9:32 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 19/42] namei: handle idmapped mounts in may_*() helpers Christian Brauner
2021-01-19 9:33 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 20/42] namei: introduce struct renamedata Christian Brauner
2021-01-19 9:34 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 21/42] namei: prepare for idmapped mounts Christian Brauner
2021-01-19 9:34 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 22/42] open: handle idmapped mounts in do_truncate() Christian Brauner
2021-01-19 9:37 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 23/42] open: handle idmapped mounts Christian Brauner
2021-01-19 9:38 ` Christoph Hellwig
2021-01-19 14:57 ` Christian Brauner
2021-01-12 22:01 ` [PATCH v5 24/42] af_unix: " Christian Brauner
2021-01-19 9:39 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 25/42] utimes: " Christian Brauner
2021-01-19 9:40 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 26/42] fcntl: " Christian Brauner
2021-01-19 9:41 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 27/42] notify: " Christian Brauner
2021-01-19 9:42 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 28/42] init: " Christian Brauner
2021-01-12 22:01 ` [PATCH v5 29/42] ioctl: " Christian Brauner
2021-01-19 9:44 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 30/42] would_dump: " Christian Brauner
2021-01-19 9:44 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 31/42] exec: " Christian Brauner
2021-01-19 9:45 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 32/42] fs: make helpers idmap mount aware Christian Brauner
2021-01-19 9:45 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 33/42] apparmor: handle idmapped mounts Christian Brauner
2021-01-12 22:01 ` [PATCH v5 34/42] ima: " Christian Brauner
2021-01-12 22:01 ` [PATCH v5 35/42] fat: " Christian Brauner
2021-01-12 22:01 ` [PATCH v5 36/42] ext4: support " Christian Brauner
2021-01-12 22:01 ` [PATCH v5 37/42] xfs: " Christian Brauner
2021-01-14 20:51 ` Dave Chinner
2021-01-14 22:10 ` Christian Brauner
2021-01-17 21:06 ` Dave Chinner
2021-01-15 16:22 ` Christoph Hellwig
2021-01-12 22:01 ` [PATCH v5 38/42] ecryptfs: do not mount on top of " Christian Brauner
2021-01-12 22:01 ` [PATCH v5 39/42] overlayfs: " Christian Brauner
2021-01-12 22:01 ` [PATCH v5 40/42] fs: introduce MOUNT_ATTR_IDMAP Christian Brauner
2021-01-19 9:47 ` Christoph Hellwig
2021-01-19 11:43 ` Christian Brauner
2021-01-12 22:01 ` [PATCH v5 41/42] tests: extend mount_setattr tests Christian Brauner
2021-01-13 0:32 ` Randy Dunlap
2021-01-12 22:01 ` [PATCH v5 42/42] generic/622: add fstests for idmapped mounts Christian Brauner
2021-01-14 17:12 ` [PATCH v5 00/42] " Darrick J. Wong
2021-01-14 17:54 ` Christian Brauner
2021-01-14 20:43 ` Dave Chinner
2021-01-15 16:24 ` Christoph Hellwig
2021-01-15 17:51 ` Theodore Ts'o [this message]
2021-01-16 0:27 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YAHWGMb9rTehRsRz@mit.edu \
--to=tytso@mit.edu \
--cc=James.Bottomley@hansenpartnership.com \
--cc=adilger.kernel@dilger.ca \
--cc=alban@kinvolk.io \
--cc=arnd@arndb.de \
--cc=casey@schaufler-ca.com \
--cc=christian.brauner@ubuntu.com \
--cc=containers@lists.linux-foundation.org \
--cc=corbet@lwn.net \
--cc=cyphar@cyphar.com \
--cc=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=djwong@kernel.org \
--cc=dmitry.kasatkin@gmail.com \
--cc=ebiederm@xmission.com \
--cc=estesp@gmail.com \
--cc=geofft@ldpreload.com \
--cc=hch@infradead.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=lennart@poettering.net \
--cc=linux-api@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mpatel@redhat.com \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=seth.forshee@canonical.com \
--cc=smbarber@chromium.org \
--cc=stephen.smalley.work@gmail.com \
--cc=stgraber@ubuntu.com \
--cc=tkjos@google.com \
--cc=torvalds@linux-foundation.org \
--cc=tycho@tycho.ws \
--cc=viro@zeniv.linux.org.uk \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).