This bug was fixed in the package zfs-linux - 0.7.5-1ubuntu5
---------------
zfs-linux (0.7.5-1ubuntu5) bionic; urgency=medium
* Fix ZFS setgid broken on 0.7 (LP: #1753288)
Pull in upstream commit 0e85048f53e4, namely:
"Take user namespaces into account in policy checks"
- Change file related checks to use user namespaces and make
sure involved uids/gids are mappable in the current
namespace.
-- Colin Ian King <[email protected]> Thu, 8 Mar 2018 09:10:00
+0000
** Changed in: zfs-linux (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1753288
Title:
ZFS setgid broken on 0.7
Status in linux package in Ubuntu:
Fix Committed
Status in zfs-linux package in Ubuntu:
Fix Released
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 : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
