3 ms·
The other part necessary to trigger the bug is that uid 0 is not root and is not able to read the user-only mounts. root would still be able to read the user-on
by dantiberian 8y ago
The other part necessary to trigger the bug is that uid 0 is not root and is not able to read the user-only mounts. root would still be able to read the user-only FUSE mount.
- kps 8y agoUser 0 is root, and it is not able to read everything on other machines — as has been the case for decades.
- dantiberian 8y agoPerhaps I misunderstood this line then? > The machine that this happened on is an NFS client and (as is usual) its UID 0 is mapped to an unprivileged UID on our fileservers. On this machine there were some FUSE mounts in the home directories of users who have their $HOME not world readable (our default $HOME permissions are owner-only, to avoid accidents). When systemd was setting up the 'slightly modified mount name-space' it attempted to access these FUSE mounts as part of binding them into the namespace, but it failed because UID 0 had no permissions to look inside user home directories. https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdDynamicUserDangerous https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdDynami...
- kps 8y agoMy reading is that (a) systemd can't read home directories on the file server, because clients understandably don't get root permissions there; and (b) the reason systemd was trying to look in those directories is that they contained (non-root-users') FUSE mount points.