LWN: Comments on "Mount namespaces and shared subtrees"

Mount namespaces and shared subtrees

imlk — Wed, 09 Jun 2021 12:47:11 +0000

Actually, the -r command in your command will create a new user namespace, and map your user ID to 0 (root) in this user namespace. That is why you can run chroot "without" root.

As mentioned in this article (https://lwn.net/Articles/532593/), starting with Linux 3.8, no privilege is required to create a new user namespace.

Mount namespaces and shared subtrees

Hi-Angel — Fri, 26 Mar 2021 01:09:04 +0000

Oh, I found in the other article, the command I was searching for is:


unshare -mr chroot ~/Projects/an-alternative-root-dir /bin/bash

This article prefixes the unshare command with # making it look as if you need root priviledges, but actually you don't need to run it as root. Running the above command as a usual user worked for me.

Mount namespaces and shared subtrees

Hi-Angel — Fri, 26 Mar 2021 00:47:19 +0000

So, I got into this article because it was linked from "unprivileged chroot" as allegedly covering most of its usecases. Sounds nice to me: at work I'm just trying to solve the problem of root required to build a system image (specifically it is running `chroot` from non-root that's causing the problem).

Okay, so I read through this article, and it even has this mention:

> Other uses include […] chroot()-style isolation of a process to a portion of the single directory hierarchy

How? I read through the whole article, and not only I don't get how to do it unpriveleged (all commands here explicitly mention root) — in fact, I don't even see an example of isolating a command to a new root.

Mount namespaces and shared subtrees

gutschke — Thu, 09 Jun 2016 16:35:47 +0000

It took me forever to debug this problem, and only after reading this LWN article did I finally figure out why my computer would crash whenever I enabled "systemd".

I have a cron job that uses "bup" to create regular snapshots of the entire filesystem. I then mount the most recent backup on "/backup". This way, I can easily recover from accidentally deleting important files or from accidentally breaking things when I make poorly conceived changes to configuration files.

For additional convenience, I also bind-mount things like "/proc" and "/dev" into this snapshot. This allows me to "chroot" into "/backup", whenever I want to see how things changed with my edits. It's been working like this for years, and the extra safety net gives great peace of mind.

Turns out, the new "systemd" policy for shared mounts means that umounting "/backup/dev/pts" also automatically unmounts the global "/dev/pts". And that has devastating effects. The system only survives very briefly afterwards.

I have a really hard time seeing how this behavior can ever be desirable for bind mounts (most notably for the "rbind" variety).

Mount namespaces and shared subtrees

grawity — Thu, 09 Jun 2016 14:42:13 +0000

The "shared" mode is probably a nicer default but it breaks mount --move as a side effect, so I've seen a few complaints when this was first added to systemd.