[PATCH v5 00/42] idmapped mounts
christian.brauner at ubuntu.com
Sat Jan 16 00:27:18 UTC 2021
On Fri, Jan 15, 2021 at 12:51:20PM -0500, Theodore Ts'o wrote:
> 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
> Is that correct? If so, how does this patch set change things (if
> any), and and how does this interact with quota administration
The cases you listed are correct. The patchset doesn't change them.
Simply put, the patchset doesn't alter capability checking in any way.
> 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?
In short, nothing changes. Whatever happened before happens now.
Specifically s_resuid/s_resgid are superblock mount options and so never
change on a per-mount basis and thus also aren't affected by idmapped
> 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. :-)
No, I really appreciate the questions. :) My brain can most likely
handle less. :)
More information about the Linux-security-module-archive