LWN: Comments on "Namespaces in operation, part 6: more on user namespaces"

Namespaces in operation, part 6: more on user namespaces

Da_Blitz — 2013-03-18T09:51:19+00:00

If none of the other options out there float your boat (LXC, unshare command or others) then you may want to try a tool i wrote to play with this from python called asylum. its available at http://code.pocketnix.org/asylum

Filesystems and security.

impossible7 — 2013-03-14T15:38:22+00:00

> However, most filesystems can not be mounted with just user namespace permissions.

Are there any plans to change this? If not, is there a reason for that?

It would be nice if an ordinary user could create a user and mount namespaces and then e.g. mount an ext4 fs from a block device that they own.

Resource limits

ebiederm — 2013-03-11T21:05:16+00:00

I don't know if userland vs kernel is the appropriate way to characterize the debate.

But yes there is a question of how unprivileged users can take advantage of the facilities cgroups offer, and how we can integrate cgroup support cleanly into containers.

Last I heard mount --bind /cgroupfs/my/group /path/to/container/cgroupfs
worked as a good approximation to what many people want.

I have not had a chance to look at it in any detail beyond that. It is nothing fundamentally hard it is just something that someone familiar with all the details needs to spend some time and to iron out.

Namespaces in operation, part 6: more on user namespaces

ebiederm — 2013-03-11T20:56:37+00:00

In the latest git of util-linux there is nsenter and unshare.

There is code in lxc.

Just for network namespaces there is code in iproute.

There is work underway to get support for multiple uids and gids per user into shadow-utils.

Resource limits

BernardB — 2013-03-11T18:05:28+00:00

I'm also interested in having cgroup management supported within namespaces. I've seen a couple of patchsets posted to LKML to attempt to achieve this - most recently from Gao Feng. It seemed to get strong opposition from Tejun Heo though, who was pushing for a userland solution: http://article.gmane.org/gmane.linux.kernel.containers/24825

I haven't seen anything more recent though.

Namespaces in operation, part 6: more on user namespaces

mathstuf — 2013-03-11T14:44:28+00:00

Is there going to be a tool to help manage namespaces (I'd guess from util-linux)?

Namespaces in operation, part 6: more on user namespaces

cstanhop — 2013-03-10T15:19:34+00:00

Yes. Thank you! This has been a great, comprehensive introduction to the namespace features.

Namespaces in operation, part 6: more on user namespaces

mathstuf — 2013-03-08T23:07:34+00:00

I was actually planning on building my own kernel RPM with user namespaces this weekend. I don't use XFS anywhere, so I'm fine with the tradeoff.

Namespaces in operation, part 6: more on user namespaces

ebiederm — 2013-03-08T22:28:12+00:00

I suspect it will have to wait until 3.10 when XFS stops turning off user namespaces.

Namespaces in operation, part 6: more on user namespaces

mathstuf — 2013-03-08T20:58:41+00:00

Looking at the config in the kernel srpm, the user namespace isn't supported even in Rawhide yet (3.9.0-rc1).

Namespaces in operation, part 6: more on user namespaces

ebiederm — 2013-03-08T19:47:52+00:00

cat /proc/config.gz | grep USER_NS

Were user namespaces enabled?

I expect the generic fedora build enables one of the filesystems that has not had a kuid/kgid conversion in 3.8 and thus can not enable user namespaces.

Namespaces in operation, part 6: more on user namespaces

alexl — 2013-03-08T17:07:34+00:00

I tried this in the latest Fedora kernel (3.8.1-201.fc18.x86_64), but it seems the user namespaces doesn't work:

./userns_child_exec -U
clone: Invalid argument

strace says:
clone(child_stack=0x7020f0, flags=CLONE_NEWUSER|SIGCHLD) = -1 EINVAL (Invalid argument)

Isn't this supposed to work in 3.8.1?

Resource limits

ebiederm — 2013-03-08T00:52:25+00:00

At a very basic level I don't see anything in any of the namespaces really being any different from any other process. The big differences are is that it is now possible to allocate kinds of resources that no one has added rlimits for, and that if /etc/subuid is setup and your users have multiple uids per user limits go from mostly useless to totally useless.

To my knowledge there is not much in the control groups that is namespace or container specific. Although I seem to remember a network memory controller that had a connection with the network namespace.

Beyond that it all depends on how heavy a sandbox you want to run. Certainly with ptrace and a firm hand you can implement very fine control on processes.

When done well I think the lightest weight solutions will live in the kernel. Certainly the cpu controller seems to live up to that notion.

But honestly whatever works and whatever is easiest.

If there is any consensus of feeling on the matter it is that cgroups are ugly but they are the best general solution we have to the problem so far.

Beyond that it looks like most of the time resource consumption is not a problem for most people. With the result that technology to implement and enforce resource limits are frequently neglected.

I hope that helps a little.

Eric

Namespaces in operation, part 6: more on user namespaces

rfrancoise — 2013-03-07T13:57:00+00:00

Thank you Michael for this fantastic article series!

Resource limits

lyda — 2013-03-07T11:36:27+00:00

What options exist or interact with this? I worked on a system that doled out memory, cpu and disk usage to a subtree of processes in a container. That was mainly handled in userland; is there work being done to manage this within the kernel or is the feeling that userland is the correct place for this?

Namespaces in operation, part 6: more on user namespaces

lyda — 2013-03-07T11:33:09+00:00

As an aside, this is why the LWN comment section is the best comment section online. In a short exchange a missing piece of info was noted, an explanation of what happens was offered, the author of the article addressed the concern and a project gets a patch that makes it better.

Not only was everything "civil," everything was positive and productive.

Namespaces in operation, part 6: more on user namespaces

mkerrisk — 2013-03-06T23:41:37+00:00

> reboot is actually a special case now

Thanks for that pointer; I'd missed that 3.9 change. I've added a strikethrough in the article. And something will make its way into the man page soonish.

Resource limits

ebiederm — 2013-03-06T20:39:54+00:00

I expect there are some system administrators out there looking at this and asking: What resources limits are in place that can be used to limit user namespaces?

The only answer at this point are memory control groups. Everything takes up memory and limiting the amount of memory used limits everything else. Unfortunately for the classic unix rlimit based resource limits fall down when multiple processes are involved.

Filesystems and security.

ebiederm — 2013-03-06T20:21:11+00:00

It is true that user namespaces allow userspace to interact with more code, and thus somewhat increases the surface one has to worry about for kernel exploits.

However, most filesystems can not be mounted with just user namespace permissions. Even for the filesystems you can mount with user namespace permissions remount is not supported. So while the cited tmpfs issue could have been a problem it it occurred elsewhere in tmpfs, it was not exploitable with user namespaces.

The recent work on converting all of the filesystems for user namespace support is essentially a constructive compiler checked proof that shows that all of the uids and gids that come from userspace are properly converted into kuids. Making it safe to use existing filesystems in the presence of multiple user namespaces.

Namespaces in operation, part 6: more on user namespaces

ebiederm — 2013-03-06T20:09:23+00:00

I believe you did miss it in an earlier article.

Those numbers are proc inode numbers, which happen to be recorded in the symlink.

If you need persistent names for any kind of namespace it is recommended that you do mount --bind /proc/PID/ns/user /a/filesystem/path.

Namespaces in operation, part 6: more on user namespaces

nix — 2013-03-06T20:06:59+00:00

They're inode numbers of /proc/$pid/ns/user. (This is an identity for the namespace because all members of a given namespace have, in effect, all their "ns/user"s hardlinked together.)

Namespaces in operation, part 6: more on user namespaces

justincormack — 2013-03-06T18:45:56+00:00

reboot is actually a special case now (though not apparently documented in the man pages). The reboot syscall in a pid namespace just sends a SIGHUP to the namespaces init process, not a real reboot, so in this sense it is also a namespace capability.

Namespaces in operation, part 6: more on user namespaces

johill — 2013-03-06T18:04:03+00:00

Hmm, what are those namespace IDs (4026531837 and 4026532318)? Those numbers are "prettier" in hex (0xeffffffd and 0xf00001de respectively) but it's not obvious (to me) where they come from. Did I miss that in an earlier article?