Public bug reported: Hey there,
We've had one of our LXD users report that setting the setgid bit inside a container using ZFS on Ubuntu 18.04 (zfs 0.7) is silently failing. This is not a LXD bug as the exact same operation works on other filesystems. There are more details available here: https://github.com/lxc/lxd/issues/4294 Reproducer looks something like: ``` root@c1:~# touch a root@c1:~# chmod g+s a root@c1:~# touch b root@c1:~# chown 0:117 b root@c1:~# chmod g+s b root@c1:~# stat a File: a Size: 0 Blocks: 1 IO Block: 131072 regular empty file Device: 43h/67d Inode: 33890 Links: 1 Access: (2644/-rw-r-Sr--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2018-03-02 03:32:47.019430367 +0000 Modify: 2018-03-02 03:32:47.019430367 +0000 Change: 2018-03-02 03:32:49.459445015 +0000 Birth: - root@c1:~# stat b File: b Size: 0 Blocks: 1 IO Block: 131072 regular empty file Device: 43h/67d Inode: 34186 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 117/postdrop) Access: 2018-03-02 03:32:50.907453706 +0000 Modify: 2018-03-02 03:32:50.907453706 +0000 Change: 2018-03-02 03:33:01.299516054 +0000 Birth: - root@c1:~# ``` And for confirmation, using a tmpfs in the same container: ``` root@c1:~# mkdir tmpfs root@c1:~# mount -t tmpfs tmpfs tmpfs root@c1:~# cd tmpfs/ root@c1:~/tmpfs# touch a root@c1:~/tmpfs# chmod g+s a root@c1:~/tmpfs# touch b root@c1:~/tmpfs# chown 0:117 b root@c1:~/tmpfs# chmod g+s b root@c1:~/tmpfs# stat a File: a Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 65h/101d Inode: 3 Links: 1 Access: (2644/-rw-r-Sr--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2018-03-02 03:33:35.783722623 +0000 Modify: 2018-03-02 03:33:35.783722623 +0000 Change: 2018-03-02 03:33:40.507750883 +0000 Birth: - root@c1:~/tmpfs# stat b File: b Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 65h/101d Inode: 4 Links: 1 Access: (2644/-rw-r-Sr--) Uid: ( 0/ root) Gid: ( 117/postdrop) Access: 2018-03-02 03:33:42.131760597 +0000 Modify: 2018-03-02 03:33:42.131760597 +0000 Change: 2018-03-02 03:33:46.227785091 +0000 Birth: - root@c1:~/tmpfs# ``` This is particularly troubling because there are no errors returned to the user, so we now have containers that will have broken binaries and permissions applied to them with no visible way to detect the problem short of scanning the entire filesystem against a list of known permissions. ** Affects: linux (Ubuntu) Importance: Critical Status: Triaged -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1753288 Title: ZFS setgid broken on 0.7 Status in linux package in Ubuntu: Triaged Bug description: Hey there, We've had one of our LXD users report that setting the setgid bit inside a container using ZFS on Ubuntu 18.04 (zfs 0.7) is silently failing. This is not a LXD bug as the exact same operation works on other filesystems. There are more details available here: https://github.com/lxc/lxd/issues/4294 Reproducer looks something like: ``` root@c1:~# touch a root@c1:~# chmod g+s a root@c1:~# touch b root@c1:~# chown 0:117 b root@c1:~# chmod g+s b root@c1:~# stat a File: a Size: 0 Blocks: 1 IO Block: 131072 regular empty file Device: 43h/67d Inode: 33890 Links: 1 Access: (2644/-rw-r-Sr--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2018-03-02 03:32:47.019430367 +0000 Modify: 2018-03-02 03:32:47.019430367 +0000 Change: 2018-03-02 03:32:49.459445015 +0000 Birth: - root@c1:~# stat b File: b Size: 0 Blocks: 1 IO Block: 131072 regular empty file Device: 43h/67d Inode: 34186 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 117/postdrop) Access: 2018-03-02 03:32:50.907453706 +0000 Modify: 2018-03-02 03:32:50.907453706 +0000 Change: 2018-03-02 03:33:01.299516054 +0000 Birth: - root@c1:~# ``` And for confirmation, using a tmpfs in the same container: ``` root@c1:~# mkdir tmpfs root@c1:~# mount -t tmpfs tmpfs tmpfs root@c1:~# cd tmpfs/ root@c1:~/tmpfs# touch a root@c1:~/tmpfs# chmod g+s a root@c1:~/tmpfs# touch b root@c1:~/tmpfs# chown 0:117 b root@c1:~/tmpfs# chmod g+s b root@c1:~/tmpfs# stat a File: a Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 65h/101d Inode: 3 Links: 1 Access: (2644/-rw-r-Sr--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2018-03-02 03:33:35.783722623 +0000 Modify: 2018-03-02 03:33:35.783722623 +0000 Change: 2018-03-02 03:33:40.507750883 +0000 Birth: - root@c1:~/tmpfs# stat b File: b Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 65h/101d Inode: 4 Links: 1 Access: (2644/-rw-r-Sr--) Uid: ( 0/ root) Gid: ( 117/postdrop) Access: 2018-03-02 03:33:42.131760597 +0000 Modify: 2018-03-02 03:33:42.131760597 +0000 Change: 2018-03-02 03:33:46.227785091 +0000 Birth: - root@c1:~/tmpfs# ``` This is particularly troubling because there are no errors returned to the user, so we now have containers that will have broken binaries and permissions applied to them with no visible way to detect the problem short of scanning the entire filesystem against a list of known permissions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1753288/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
