Rights / ownership on unprivileged container rootfs

LXD
1

Hello,

I’m having an issue while trying to create an unprivileged container with lxd. The rootfs of the created container is still owned by root and not by the uid/gid that i expected.

Version :

lxc --version
4.19

Configuration :

bat /etc/sub*
       │ File: /etc/subgid
   1   │ sysadmin:100000:6553
   2   │ root:1000000:65536

       │ File: /etc/subuid
   1   │ sysadmin:100000:65536
   2   │ root:1000000:65536

bat /etc/lxc/*
       │ File: /etc/lxc/default.conf   <EMPTY>
       │ File: /etc/lxc/lxc.conf   <EMPTY>
       │ File: /etc/lxc/lxc-usernet   <EMPTY>

When i try to create a container it works fine :

lxc launch images:alpine/edge toto
Creating toto
Starting toto

The idmap of the container seems coherent with the subuid / subgid declared :

lxc config show toto |grep idmap
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[]'

However when i look at the rootfs it is not the owner / group i was expecting :

sudo stat /var/lib/lxd/storage-pools/default/containers/toto
  File: /var/lib/lxd/storage-pools/default/containers/toto
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: fd01h/64769d	Inode: 917510      Links: 4
Access: (0100/d--x------)  Uid: (1000000/ UNKNOWN)   Gid: (    0/    root)
Access: 2021-10-09 17:33:47.503552141 +0200
Modify: 2021-10-09 17:33:47.639558388 +0200
Change: 2021-10-09 17:33:47.681560317 +0200
 Birth: 2021-10-09 17:33:47.503552141 +0200

sudo stat /var/lib/lxd/storage-pools/default/containers/toto/rootfs
  File: /var/lib/lxd/storage-pools/default/containers/toto/rootfs
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: fd01h/64769d	Inode: 917526      Links: 19
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-10-08 15:01:42.000000000 +0200
Modify: 2021-10-08 15:01:42.000000000 +0200
Change: 2021-10-09 17:33:47.628557882 +0200
 Birth: 2021-10-09 17:33:47.509552416 +0200

What is particularly strange is that the path /var/lib/lxd/storage-pools/default/containers/toto is owned by the “correct” uid but not the correct group, and the rootfs itself is owned by root.

Is it a misconfiguration on my part ? Or something that i misunderstood about the expected behaviour ?

Thank you in advance for your responses.

2

Looks like you’re running on a system which either supports shiftfs or supports VFS based shifting and so doesn’t need an actual rewrite of all uid/gid on the filesystem.

You can check that the mapping is in place by looking at /proc/self/uid_map and /proc/self/gid_map in the container. If it’s shiftfs, you’ll see it with grep shiftfs /proc/self/mountinfo in the container too. If it’s the new VFS shifting in the kernel, then you won’t see it but your kernel will be 5.12 or newer and your container’s filesystem will be on either ext4 or xfs.

3

Hello,

Thank you very much for your answer.

I can see the mapping in the files you specified :

lxc exec toto -- /bin/sh
~ # cat /proc/self/uid_map
         0    1000000      65536
~ # cat /proc/self/gid_map
         0    1000000      65536
~ # grep shiftfs /proc/self/mountinfo
~ # cat /proc/self/mountinfo
449 341 253:1 /var/lib/lxd/storage-pools/default/containers/toto/rootfs / rw,relatime,idmapped master:1 - ext4 /dev/disk/by-uuid/665fddc7-f4aa-4c33-86cc-0e7a89d3402c rw
...

There is nothing in mountinfo regarding shiftfs but the container filesystem is indeed on ext4 and the kernel is more recent than 5.12 as you said so it must be the VFS shifting as you mentioned :

uname -a
Linux nixos 5.14.8-zen1 #1-NixOS ZEN SMP Tue Jan 1 00:00:00 UTC 1980 x86_64 GNU/Linux

Thank you again for you answer, that was spot on !

4

Ah yeah, the mount entry shows idmapped so you’re indeed using the new VFS idmapped feature that @brauner got into the 5.12 kernel.

5

@stgraber this seems similar to what I’m seeing here, although this can be useful is there a way to disable it? Or, even better, disable it for the container’s root fs? I don’t want to have dubious permission issues and strange behaviors down the line.