Re: [PATCH v2 00/28] user_namespace: introduce fsid mappings

2 messages, 2 authors, 2020-02-16 · open the first message on its own page

Re: [PATCH v2 00/28] user_namespace: introduce fsid mappings

From: Florian Weimer <hidden>
Date: 2020-02-16 15:57:52

* Christian Brauner:
With fsid mappings we can solve this by writing an id mapping of 0
100000 100000 and an fsid mapping of 0 300000 100000. On filesystem
access the kernel will now lookup the mapping for 300000 in the fsid
mapping tables of the user namespace. And since such a mapping exists,
the corresponding files will have correct ownership.
I'm worried that this is a bit of a management nightmare because the
data about the mapping does not live within the file system (it's
externally determined, static, but crucial to the interpretation of
file system content).  I expect that many organizations have
centralized allocation of user IDs, but centralized allocation of the
static mapping does not appear feasible.

Have you considered a more complex design, where untranslated nested
user IDs are store in a file attribute (or something like that)?  This
way, any existing user ID infrastructure can be carried over largely
unchanged.

Re: [PATCH v2 00/28] user_namespace: introduce fsid mappings

From: Christian Brauner <hidden>
Date: 2020-02-16 16:41:21

On Sun, Feb 16, 2020 at 04:55:49PM +0100, Florian Weimer wrote:
* Christian Brauner:
quoted
With fsid mappings we can solve this by writing an id mapping of 0
100000 100000 and an fsid mapping of 0 300000 100000. On filesystem
access the kernel will now lookup the mapping for 300000 in the fsid
mapping tables of the user namespace. And since such a mapping exists,
the corresponding files will have correct ownership.
I'm worried that this is a bit of a management nightmare because the
data about the mapping does not live within the file system (it's
externally determined, static, but crucial to the interpretation of
file system content).  I expect that many organizations have
Iiuc, that's already the case with user namespaces right now e.g. when
you have an on-disk mapping that doesn't match your user namespace
mapping.
centralized allocation of user IDs, but centralized allocation of the
static mapping does not appear feasible.
I thought we're working on this right now with the new nss
infrastructure to register id mappings aka the shadow discussion we've
been having.
Have you considered a more complex design, where untranslated nested
user IDs are store in a file attribute (or something like that)?  This
That doesn't sound like it would be feasible especially in the nesting
case wrt. to performance.

Christian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help