Hi, I just started to use LXD and have version 4.4 installed through snap on Ubuntu 20.04.
I have tried to make a shared folder by adding a disk device to the container, add ID mappings to raw.idmap, and edit /etc/subXid to allow LXD to use those uids/gids. However, the shared files show up as with uid:gid nobody:nogroup. Then I read somewhere that my snap-installed LXD cannot access the /etc/subXid files.
Is there another way of sharing a directory between the host and a few containers?
gustav@fridolf:~$ lxc launch ubuntu:20.04 test
Creating test
Starting test
gustav@fridolf:~$ lxc config device add test share disk source=/tank/video path=video
Device share added to test
gustav@fridolf:~$ ls -l /tank/video
total 51
drwxr-xr-x 4 media media 34 Aug 6 13:04 dvd
drwxr-xr-x 4 media media 48 Aug 5 15:45 film
drwxr-xr-x 19 media media 19 Aug 5 21:28 tv
gustav@fridolf:~$ id media
uid=1001(media) gid=1001(media) groups=1001(media)
gustav@fridolf:~$ lxc config set test raw.idmap='both 1001 1000'
gustav@fridolf:~$ lxc restart test
gustav@fridolf:~$ lxc exec test -- ls -l /video
total 3
drwxr-xr-x 2 nobody nogroup 2 Aug 5 09:19 dvd
drwxr-xr-x 2 nobody nogroup 2 Aug 5 09:18 film
drwxr-xr-x 2 nobody nogroup 2 Aug 5 09:19 tv
gustav@fridolf:~$ lxc config device add test share disk source=/tank/video path=/video shift=true
Error: Failed to start device “share”: Failed to add mount for device inside container: Failed to run: /snap/lxd/current/bin/lxd forkmount lxd-mount – 66374 3 /dev/.lxd-mounts/lxdmount_794817290 video true: Failed to mkdir video: Permission denied
Hmm, sounds like the container didn’t properly re-shift during its restart?
Try restarting it again and then check that ls -lh / in the container looks okay?
Excellent! shiftfs is definitely the direction we’re going with on this. It’s currently opt-in (as you’ve noticed) because there are still some rough edges but the only issue I’m aware of right now affects btrfs, I have many systems using it on zfs, so far without issues.
Well, it didn’t quite work out as I expected. The /video directory is owned by 1001:1001, as on the host, but the subdirectories (dvd, film and tv) are owned by root:root and are empty.
shiftfs effectively makes all access to the particular mount get unshifted before hitting the real mount on the host.
The main advantage is that every uid/gid in the container can be represented on it and so can use the mount as they normally would.
A potential security concern depending on visibility and access to the path on the host is that root in your container can create setuid files in the path which are then real setuid root binaries on the host. This can be prevented by having the mount on the host be nosuid or be hidden away from untrusted users.
A security advantage of shiftfs is that the container map does not need to be changed, so uid 1001 in your container is still 101001 at the kernel level and not 1001 as would be with a raw.idmap entry, so this prevents the container from doing resource denial of service attacks on a uid.