How does something like Podman handle bind mounts without requiring root?

#podman

@jarkko presumably mount namespaces, you can bind mount inside "unshare -rm"

@vegard Right, "--map-root-user" was the thing I was probably looking for, thanks.

@vegard,

Here’s an example:

sudo unshare \
  --mount \
  --uts \
  --root "$ROOTFS" \
  sh -c "
    mkdir -p /proc
    mkdir -p /sys
    mkdir -p /dev
    mount -t sysfs /sys /sys
    mount -t proc /proc /proc
    mount -t devtmpfs /dev /dev
    mount -t devpts /dev /dev/pts
    hostname $MACHINE
    su -c '$CMDLINE' $USER
  "

If I took sudo away, the mounts would fail on permission error, even with --map-root-user.

It’s even expected outcome, because if such tweak would work, it would be a privilege escalation i.e., a security vulnerability.

Still wondering what is the magic dust Podman uses here :-)

@jarkko @vegard oh hello --map-root-user. i think i added that option back in the day. hail satan!

@lkundrak @vegard As open-coded apparently "--map-user=0 --map-group=0". Great now I know at least what it does.

Probably "--map-auto" makes sense too for using uid/gid maps.

The goal here is to just substitute "systemd-nspawn" in a build with something that uses as little features as possible so that the build nests nicely with Github/Gitlab CI or anything. And do a home-baked container wrapper in order not to add dependencies ...

I need to check how systemd-nspawn and podman handle /dev etc. mappings from the implementation 🙂

@lkundrak @vegard getting rid of /dev was at least dead easy:

+# Debootstrap populates `/dev/{null,zero,full,random,urandom,tty}`, meaning that
+# mounting devtmpfs to `/dev` is not required.
 sudo unshare \
   --mount \
   --uts \
   --root "$ROOTFS" \
   sh -c "
-    mkdir -p /proc
-    mkdir -p /sys
-    mkdir -p /dev
-    mount -t sysfs /sys /sys
     mount -t proc /proc /proc
-    mount -t devtmpfs /dev /dev
     mount -t devpts /dev /dev/pts
     hostname $MACHINE
# ...

I think I can iterate from this :-) E.g, proc-mount can be probably (I’d guess) made unprivileged with “–fork –pid” i.e., creating PID namespace.

@lkundrak @vegard And if I ever need to get away from Debootstrap I can probably just:

mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/full c 1 7
mknod /dev/random c 1 8
mknod /dev/urandom c 1 9
mknod /dev/tty c 5 0

@jarkko @lkundrak for proc you can always do unshare -rnpf --mount-proc

@vegard @lkundrak OK yet another option I was not aware about, thanks :-)

@vegard @lkundrak TBH, I'm quite newbie with namespaces. I've just stuck before to VMs because they are so much easier. Now I actually needed a container for the first time ever (to substitute systemd-nspawn in a build).

@jarkko @lkundrak Namespaces let you do some cool things, but I am not convinced the complexity is worth it in the end.

@vegard @lkundrak Yeah, not eagerly exploring on topic :-) Now I know enough to wrap a shitty build container with bash and unshare, which will cover at least the next 5+ years ;-)

@jarkko @vegard yes now that you've figured it out, shall we praise satan??

@lkundrak @vegard sure \,,/