Bind mounting possible inside rootless container

[tobiasjakobi-lr]

Hello,

I wanted to inquire if it is somehow possible to allow bind mounting from inside a rootless container.

The reason for the question is that I'm trying to "reorganize" the OCI containers of our team. And it turns out that there is one container, which only works with rootfull Docker in privileged mode.

This container contains another rootfs, which is then entered via schroot.

As I'm not a big fan of running any kind of container technology as root, I'm looking into ways to get all this running in rootless (and possibly unprivileged) Podman containers. This proves to be difficult as schroot does some bind mounting internally and then fails.

devel@d16d1a10a430:~/workspace$ sudo schroot -c chroot:devserver-arm64 -- /bin/bash
E: 10mount: mount: /run/schroot/mount/devserver-arm64-189e59a0-0ed3-4b16-8351-5fc72366ef4a: permission denied.
E: 10mount:        dmesg(1) may have more information after failed mount system call.
E: 15binfmt: update-binfmts: unable to open /var/run/schroot/mount/devserver-arm64-189e59a0-0ed3-4b16-8351-5fc72366ef4a/bin/sh: No such file or directory
E: devserver-arm64-189e59a0-0ed3-4b16-8351-5fc72366ef4a: Chroot setup failed: stage=setup-start

In fact I get the same "permission denied" error when manually trying to bind mount something trivial. So mounting is a problem. No idea if chroot() becomes the new problem once this is solved, but I'm going one step at a time here.

Any ideas on how to solve this? Or maybe it's just not technically possible and this whole "nested rootfs" business is a bad idea anyway.

Thanks in advance!

With best wishes,
Tobias

[Luap99]

You provide no details how the podman container is created/run so it hard to tell what is wrong.
At minimum you would need --cap-add SYS_ADMIN if you want to mount things. Or alternatively create a new userns inside the container with all the caps

[tobiasjakobi-lr]

Sorry, I was under the impression that this is a generic question that doesn't depend all that much on the container in use.

Anyway, I run the container like this.

podman container run --rm --interactive --tty --userns=keep-id:uid=1000,gid=1000 --volume ${HOME}/repos:/home/devel/workspace <image name or ID> /bin/bash

There is a user devel inside the container, which has UID/GID 1000:1000.

And I don't think that --cap-add SYS_ADMIN works here, as I can only modify capabilities that I already have as the user running the container.

[Luap99]

Yes you will need --cap-add SYS_ADMIN or --privileged (if you want all caps and less restrictions)
Rootless podman runs in a user namespace with all capabilities but then for the container drops most of them including SYS_ADMIN which is required to perform a bind mount in the user namespace.

[tobiasjakobi-lr]

I'm not sure I follow you: The Podman documentation about the --privileged option says:

Rootless containers cannot have more privileges than the account that launched them.

My interpretation of this is: If the user (outside the container), who launches the container, doesn't already have SYS_ADMIN, then, how is Podman supposed to give the container use (the one inside) this cap? Or are capabilities also namespaced?

Thanks for helping!

[Luap99]

Or are capabilities also namespaced?

Yes they are, that is what makes user namespace secure, see user_namespaces(7)

Holding CAP_SYS_ADMIN within the user namespace that owns a process's mount namespace allows that process to create bind mounts ...

[tobiasjakobi-lr]

Well, that explains a lot! I always had the impression that caps were "global" and the statement from the docu talked about caps as a "subset" of privileges.

Thanks again for clearing that up!