ZFS setgid broken on 0.7
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Critical
|
Colin Ian King | ||
Bionic |
Fix Released
|
Critical
|
Colin Ian King | ||
zfs-linux (Ubuntu) |
Fix Released
|
Critical
|
Colin Ian King | ||
Bionic |
Fix Released
|
Critical
|
Colin Ian King |
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:/
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.
CVE References
Changed in zfs-linux (Ubuntu): | |
importance: | Undecided → Critical |
Changed in linux (Ubuntu): | |
status: | Triaged → In Progress |
Changed in zfs-linux (Ubuntu): | |
status: | New → In Progress |
assignee: | nobody → Colin Ian King (colin-king) |
Changed in linux (Ubuntu): | |
status: | In Progress → Fix Committed |
tags: |
added: kernel-fixup-verification-needed-bionic removed: verification-needed-bionic |
tags: | added: cscc |
Just checking, is this a regression in ZFS 0.7.x?