Shiftfs provides write access on read-only share?

LXD
,
1

Hi, I have a use case where my media files are shared with multiple LXD containers. Most containers do not require write access to these shares. Therefore I share the data read-only.
See my example below how it is configured.

Adding multimedia shares to MS2 on host (in /etc/rc.local):
mount --bind “/storage0/NAS1/user/Mijn bestanden/Mijn muziek” /storage0/MS2/music-ro
mount -o remount,ro,bind /storage0/MS2/music-ro

Add shares to MS2 (LXD minidlna container):
lxc config device add MS2 md2 disk source=/storage0/MS2/music-ro path=/storage0/music

This worked on Ubuntu 16.04-LTS with LXD version 2.x and 3.x

Now migrated to Ubuntu 20.04-LTS:
$ lxd version
4.0.7
$ snap version
snap 2.51.3
snapd 2.51.3
series 16
ubuntu 20.04
kernel 5.4.0-81-generic

Sharing folders this way does not work anymore. The shared folder is empty from within the container due to the nouser/nogroup attributes of the files and folders, probably because my lxd-host and container are no member of my domain. I enabled shiftfs to make the content of the share visible.

Add shares to MS2 (LXD minidlna container):
lxc config device add MS2 md2 disk source=/storage0/MS2/music-ro path=/storage0/music shift=true

This way the container has access to the content of the share, great.

Sadly I noted that now it is possible to write to the share! It does not make sense to me because from the host it is not possible to write to /storage0/MS2/music-ro. Even root is not allowed to write to this folder. But from within the container root has complete write access on the source files in “/storage0/NAS1/user/Mijn bestanden/Mijn muziek”.

I do not understand what is going on here. It might be an bug or not, but I do not like it. Is this normal?

2

Can you provide the output of cat /proc/mounts from the LXD host and inside the container please.

Can you also try setting readonly=true on the disk device you added, e.g.

 lxc config device set MS2 md2 readonly=true

https://linuxcontainers.org/lxd/docs/master/instances#type-disk

@brauner does shiftfs bypass the host’s own mount read-only restrictions?

3

It may depend on how the host is setup. shiftfs can’t bypass a read-only superblock bit, but it may get past a read-only bind-mount flag as it will effectively itself become a new mount of the underlying superblock.

1 Like
4

This should be fixed in:

commit 06d7ed007e4f3e1d5218a3ac41e63bd7972a64b6 (origin/2021-02-17/fixes)
Author: Christian Brauner <christian.brauner@ubuntu.com>
Date:   Wed Feb 17 10:57:16 2021 +0100

    driver_lxc: pass flags to shiftfs mount

    Link: https://discuss.linuxcontainers.org/t/mount-home-directory-read-only-permission-denied
    Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

which seems to not have made it into 4.0.7 at least according to:

git tag --contains  06d7ed007e4f3e1d5218a3ac41e63bd7972a64b6

lxd-4.12
lxd-4.13
lxd-4.14
lxd-4.15
lxd-4.16
lxd-4.17
5

The backported version has a different hash:

stgraber@dakara:~/data/code/lxc/lxd (lxc/stable-4.0)$ git tag --contains c1c6f667d7095581dbb2dee92cbf8ccaffc3be93
lxd-4.0.6
lxd-4.0.7
9

Thanks for all the replies. See output below it confirms the container gains unexpected read/write access.

user@server:~$ cat /proc/mounts
/dev/md1 /storage0/MS2/movies-ro ext4 ro,nosuid,nodev,relatime 0 0
/dev/md1 /storage0/MS2/music-ro ext4 ro,nosuid,nodev,relatime 0 0

root@MS2:~# cat /proc/mounts
/var/snap/lxd/common/lxd/devices/MS2/disk.md1.storage0-movies /storage0/movies shiftfs rw,relatime,passthrough=3 0 0
/var/snap/lxd/common/lxd/devices/MS2/disk.md2.storage0-music /storage0/music shiftfs rw,relatime,passthrough=3 0 0

I added the readonly setting:
lxc config device set MS2 md2 readonly=true

Result, it is now read only! This works, but I think you agree most people will forget to do this. hopefully it will be fixed in lxd 4.0.x soon.