4 ms·
Everything that would have been "a weird problem with Foo Daemon's init script" we now call "a weird problem with systemd". So you think that systemd-timesyncd
by LukeShu 8y ago
Everything that would have been "a weird problem with Foo Daemon's init script" we now call "a weird problem with systemd".
So you think that systemd-timesyncd's service file shouldn't choose the uid at service-start time.
That's not really the issue though. The issue is that for service isolation reasons (related to choosing the uid at service-start time), the service file wants to run systemd-timesyncd in a private mount namespace, but it is failing to properly set up that namespace. That's a more general issue, as there are a number of things that could trigger running the service in a private mount namespace; not just DynamicUser.
- erik_seaberg 8y agoIf SELinux doesn't cut it and you actually need to jail a badly-behaved service, "set up a jail in this specific way and exec this process in it" should be a tool to be invoked by an init script or a unit file or whatever. unshare(1) looks like it's halfway there.
- LukeShu 8y agoThat's exactly what's going on here. The systemd service launcher is doing the same thing as unshare(1); calling unshare(2). However, by "default" after you `unshare --mount`/`unshare(CLONE_NEWNS)`, changes made to existing mounts can propagate to the parent namespace, so then you need to do something like `mount --make-rslave /` to complete the isolation. As I understand the bug, the problem is in systemd's version of the `mount --make-rslave /` step, which (for a reason unknown to me) tries to stat (as root) the mountpoint first, and if the mountpoint is on a remote FS that might fail, and systemd isn't correctly handling that.