Namespaces in operation, part 5: User namespaces

Posted Feb 27, 2013 19:50 UTC (Wed) by nix (subscriber, #2304)
Parent article: Namespaces in operation, part 5: User namespaces

Simply excellent documentation. Would that all docs were like this.

Namespaces in operation, part 5: User namespaces

Posted Feb 27, 2013 19:59 UTC (Wed) by einstein (guest, #2052) [Link] (5 responses)

It looks like we're oh so slowly and painfully discovering and re-inventing openvz a little bit at a time. Hopefully we'll get there before too many more years.

Namespaces in operation, part 5: User namespaces

Posted Feb 27, 2013 20:52 UTC (Wed) by SEJeff (guest, #51588) [Link] (3 responses)

@einstein: Parallels (virtuozzo/openvz authors) have been some of the primary contributors to the upstream namespace support in the kernel. While I cringe at seeing the 1Mb+ patch that openvz is, I've got to give them props for going about things the right (and very long) way of getting small bits upstream at a time.

Namespaces in operation, part 5: User namespaces

Posted Feb 27, 2013 22:34 UTC (Wed) by mabshoff (guest, #86444) [Link] (2 responses)

Well, I am not quite sure where the 1 MB patch figure comes from, but all the RHEL 6.x based patches weigh in at 27 MB unpacked. Note that this is 2.6.32 vanilla -> RHEL 6.x+ovz, so I do assume that the vast majority of that diff is the RHEL 6.x changes. Either way, as you mentioned a massive amount of code from the people working for Parallels has been merged, so I would be curious what the RHEL 7.0 diff will look like. I guess we will know in a couple months.

Cheers,

Michael

Namespaces in operation, part 5: User namespaces

Posted Feb 28, 2013 4:25 UTC (Thu) by SEJeff (guest, #51588) [Link] (1 responses)

From a quick google, I found this:
http://openvz.org/Kernel_build#Rebuilding_kernel_from_sou...

[jeff@omniscience tmp]$ wget -q http://download.openvz.org/kernel/branches/2.6.18/028stab...
[jeff@omniscience tmp]$ du -hs patch-ovz028stab056.1-combined.gz
1.2M patch-ovz028stab056.1-combined.gz
[jeff@omniscience tmp]$ gzip -d patch-ovz028stab056.1-combined.gz
[jeff@omniscience tmp]$ du -hs patch-ovz028stab056.1-combined
4.6M patch-ovz028stab056.1-combined

I did the same thing about a year ago and the results were the same. So I still stand by my previous comment. Around a megabyte :)

Namespaces in operation, part 5: User namespaces

Posted Feb 28, 2013 14:33 UTC (Thu) by mabshoff (guest, #86444) [Link]

> From a quick google, I found this: [SNIP]

Yeah, that was the first hit I got, too, but I discarded it for the reason listed below.

> So I still stand by my previous comment. Around a megabyte :)

Well, that specific patch is for a RHEL 5 based kernel, i.e. on top of their version of 2.6.18. The RHEL 6 based 2.6.32 kernel patch weights in at currently 1.3 MB (see [1]). And that patch dates from March 4th 2011, so I would hardly call it current :p.

Anyway, with ploop and some of their other bits being out of mainline for now their patch is a little like the RT patch set: growing some time and shrinking some other time, but as patches move into mainline from it new patches for new functionality get added on top. At least after many years of living mostly out of mainline their efforts like CRIU have shown that you can merge it into mainline assuming all interested parties collaborate, and that is a really positive development imho.

Cheers,

Michael

[1] http://download.openvz.org/kernel/branches/2.6.32/2.6.32-...

Namespaces in operation, part 5: User namespaces

Posted Feb 27, 2013 22:11 UTC (Wed) by ebiederm (subscriber, #35028) [Link]

Oh I would say that the user namespaces at least are much closer to the original vserver approach (which uses a fixed number of the high bits as the container id) and fair bit better than either approach as all of the weird corner cases of mixing userspace uids and gids and the kernel uids and gids are handled.

That is what the remaining XFS work is about ensuring that XFS doesn't mix user space uids with in-kernel uids without adding the appropriate translations, and making it hard to mess confuse those two kinds of uids in the future. XFS has a very unique architecture for it's in-kernel filesystem data structures and many more user facing ioctls than most filesystems which means it can't be treated like just another filesystem.

What was not mentioned is that when a process in a user namespace interacts files, the interaction is the same as interacting with processes. When a file is created the uid of the process is mapped into the initial user namespace those mapped uids are stored on disk. Meanwhile when the process in a user namespace stats those files the uids are mapped back into it's namespace so it sees the uids it wrote with instead of the uids that are stored on disk.

This allows quotas and other filesystem features to work with user namespaces without any changes to the on-disk format.