3 ms·

You obviously didn't read the article before deciding this wasn't systemd's fault. The bug is the lack of any error handling in the DynamicUser feature of syst

by gnud 8y ago

You obviously didn't read the article before deciding this wasn't systemd's fault. The bug is the lack of any error handling in the DynamicUser feature of systemd. The original failure is not logged anywhere - and launching timesyncd just goes ahead even though the setup for it fails completely. Naturally timesyncd then fails to start. (Or perhaps the bug is the whole DynamicUser feature. From reading the bug report, it looks like it will fail any time anyone has a user-only FUSE mount point on their system...)

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 ago
  User 0 is root, and it is not able to read everything on other machines — as has been the case for decades.
  - dantiberian 8y ago
    Perhaps 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 ago
      My 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.

by gnud 8y ago

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 ago
User 0 is root, and it is not able to read everything on other machines — as has been the case for decades.
- dantiberian 8y ago
  Perhaps 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 ago
    My 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.