LWN: Comments on "Filesystem UID mapping for user namespaces: yet another shiftfs"

Filesystem UID mapping for user namespaces: yet another shiftfs

helsleym — Wed, 19 Feb 2020 18:00:14 +0000

Seems to me that not exposing the FSID is a big advantage of the other approaches. Keeping them an internal detail of the kernel that userspace need not be concerned with and expecting userspace to deal with (bind) mounts instead -- as it already does -- seems conceptually simpler to me in addition to the already-mentioned flexibility advantages.

Filesystem UID mapping for user namespaces: yet another shiftfs

jejb — Wed, 19 Feb 2020 03:01:30 +0000

Since I wasn't present for all the discussions, I'm not entirely sure this is what was discussed. However, I do think putting the unpacker in a user namespace is how this is supposed to work. As you say this avoids all the chown dances. This also starts deprivileging pieces of kubernetes as well which people are finally starting to agree is a good thing.

Filesystem UID mapping for user namespaces: yet another shiftfs

roc — Tue, 18 Feb 2020 19:53:27 +0000

How would an in-kernel container ID help here?

Filesystem UID mapping for user namespaces: yet another shiftfs

dezgeg — Tue, 18 Feb 2020 16:11:22 +0000

> Also, if this is container related, presumably we’d rather not leave container cruft behind on files in a file system that is just being temporarily used.

Yes, this is a good point. Also, what would happen if two different containers need to share the same filesystem from host. Or how would one give a read-only filesystem to a container.

Filesystem UID mapping for user namespaces: yet another shiftfs

vgoyal — Tue, 18 Feb 2020 16:09:39 +0000

I am wondering why is it being called shiftfs equivalent. IIUC, on disk UID is not container UID. That's going to be translated UID. I thought with shiftfs, container created files showed on disk with container UID. Shiftfs also solved the issue of not having to do chmod. This patchset will still require doing a chmod (until and unless images have been pulled from inside the user namespace). Am I missing something.

Filesystem UID mapping for user namespaces: yet another shiftfs

jejb — Tue, 18 Feb 2020 15:28:54 +0000

> this one involves a theoretically simpler approach that makes almost no changes to the kernel's filesystem layer at all.

The diffstat doesn't entirely support that:

Filesystem UID mapping for user namespaces: yet another shiftfs

Paf — Tue, 18 Feb 2020 14:11:25 +0000

Sure, but why add another?

Also, if this is container related, presumably we’d rather not leave container cruft behind on files in a file system that is just being temporarily used.

Filesystem UID mapping for user namespaces: yet another shiftfs

snajpa — Tue, 18 Feb 2020 12:02:21 +0000

So, another +1 for User namespace awkwardness...

So you see, it would still be a bad idea to have in kernel container id, lol.

Let's continue on rather with this madness and keep smiling, like everything is just ok :-D

Filesystem UID mapping for user namespaces: yet another shiftfs

edomaur — Tue, 18 Feb 2020 09:13:17 +0000

It would be slower but you probably can. However you will still need to implement the container UID perspective somewhere : in the SELinux case, you need to add a whole bunch of hooks in the process and filesystem management parts in the kernel, so it would probably be something quite intrusive too.

Filesystem UID mapping for user namespaces: yet another shiftfs

dezgeg — Tue, 18 Feb 2020 08:12:41 +0000

Don't you already get one per file when using something like SELinux?

Filesystem UID mapping for user namespaces: yet another shiftfs

willy — Tue, 18 Feb 2020 00:50:56 +0000

You want to add an xattr to every file? They're not free, you know

Filesystem UID mapping for user namespaces: yet another shiftfs

tau — Tue, 18 Feb 2020 00:21:36 +0000

I wonder why a container-local UID can't be stored in an xattr instead.