Behavior of unprivileged container with restricted idmap

[aw32]

Certain actions do not work with unprivileged containers and restricted idmap.

1. Bind mounting of (host) root accessible paths
   For an example path /path/to/folder/ and the path permissions:

drwx------ root root /path
drwx------ root root /path/to
drwx------ 1000 1000 /path/to/folder

I expected it would be possible (lxc started as root) to mount /path/to/folder inside the container rootfs with the container uid 100 mapped to the real uid 1000

lxc.init.uid = 100
lxc.init.gid = 100
lxc.idmap = u 100 1000   1
lxc.idmap = g 100 1000   1
lxc.mount.entry = /path/to/folder /path/inside/container none bind 0 0

However, this fails due to lxc first dropping to the unprivileged user and afterwards trying to mount the path.
(This also fails if there is a unprivileged root user specified.)

2. lxc-attach to unprivileged container
   lxc-attach fails if there is no root user inside the container specified (see example config from point 1.).
   Error message: Permission denied - Failed to create leaf cgroup ".lxc"
   It's possible to fix this by adding an unprivilieged root user, e.g.

lxc.idmap = u 0 100000 1
lxc.idmap = g 0 100000 1

---

I guess this is intended behavior?
In this case it would be nice to reflect this in the documentation.

[brauner]

In order to mount you need to be CAP_SYS_ADMIN in the user namespace of the container's mount namespace. We usually at least temporarily map uid 0 in the container to the a uid on the host otherwise setting up the container is not easy to do. In any case, I think this is intended behavior but let me see whether we can improve the leaf cgroup creation.