shiftfs: broken shiftfs nesting
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Christian Brauner | ||
Eoan |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
SRU Justification
Impact: When nested containers use shiftfs and they have different id mappings the nested container lacks privileges to create any files in its root filesystem unless the directory in question is very permissive. This prevents nested containers from being usable.
Here is a reproducer as given by Stéphane:
Reproducer:
- lxc init images:
- Confirm b1 uses shiftfs and uses the default map
root@b1:~# cat /proc/self/uid_map
0 1000000 1000000000
root@b1:~# grep shiftfs /proc/self/
3702 2266 0:92 / / rw,relatime - shiftfs /var/lib/
- Install LXD snap in there
- snap set lxd shiftfs.enable=true
- systemctl reload snap.lxd.daemon
- lxd init --auto
- lxc launch images:alpine/edge a1
- Confirm that a1 uses a different map than b1
- Confirm that a1 uses shiftfs
- touch /etc/a should fail with EACCES
Fix: Instead of recording the credentials of the process that created the innermost shiftfs mount we need to record the credentials of the lowers creator of the first shiftfs mark mount since we always refer back to the lowers mount to get around vfs layering restrictions.
Regression Potential: Limited to shiftfs.
Test Case: Built a kernel with the mentioned fix and ran the reproducer. The issue was not reproducible.
CVE References
Changed in linux (Ubuntu Eoan): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu Focal): | |
status: | New → Fix Committed |
tags: |
added: verification-done-eoan verification-done-focal removed: verification-needed-eoan verification-needed-focal |
Changed in linux (Ubuntu): | |
status: | In Progress → Fix Committed |
See /github. com/brauner/ ubuntu- unstable/ commits/ 2020-04- 10/shiftfs_ nesting
https:/
for fix.