3 ms·

systemd's job is to start daemons. It can be reasonable to decide dynamically when to start them based on which others are healthy (maybe you care more about sp

systemd's job is to start daemons. It can be reasonable to decide dynamically when to start them based on which others are healthy (maybe you care more about speed than determinism on a laptop). But there's no reason to choose a uid and mkdir dynamically. You want these errors at install time, not at the box's next (probably unattended) restart.

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 ago
  If 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 ago
    That'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.
jack9 8y ago
> systemd's job is to start daemons But that's not all it does and the dependencies of systemd alongside making systemd a dependency, results in a very different observable reality.
jhoechtl 8y ago
And do the logging. My only gripe is that it logs in a binary format requiring special tools to read the logs. Otherwise systemd is a marvel.
lomnakkus 8y ago
Personally, I think even having to choose a UID at install time or dynamically is a pretty sad indictment of just how broken the user system on Linux (and pretty much every UNIX-like) is. It leads to a huge amount of incidental complexity where there's a much simpler way: User IDs should just be randomly chosen UUIDs -- either generated by upstreams or by the distros. Any metadata attached to the user UID could just be preinstalled for all possible daemons[0] -- and it should be separate from the mutable /etc/passwd stuff. Obviously there's so much inertia in the existing system that it could realistically never happen at this point, but one can dream, right? [0] Kind of like e.g. /etc/services but with UUIDs.
- fowl2 8y ago
  Except of course if you want multiple instances of the same daemon
  - lomnakkus 8y ago
    Um, mix in a second randomly-chosen UUID? My point wasn't so much that I had the perfect solution and that I'd thought of everything. It's that there are much better systems and that we should actually strive to get there.
- JdeBP 8y ago
  One can, and many people have, over the years. Some of the more interesting ideas that people have had, in my view, have been: * ID systems that introduce hierarchies, allowing (say) a user to create multiple sub-users (one for running the WWW browser, one for running the office suite, one for running the chat program, ...); * proper nonce ID creation with segregation guarantees (c.f. nonce SIDs in the Windows NT world); and * IDs that are reference counted, accessible via descriptors, passable from process to process via descriptor-passing mechanisms, and explicitly supplied in system calls for opening/creating things.
JdeBP 8y ago
Actually, wanting this stuff not at install/configure time is one of the primary driving forces behind the mechanism. Lennart Poettering notes that it moves the relevant tasks out of package pre/post-install/deinstall scripts and into service startup and shutdown. Ironically, the alternative approach here is more descriptive and less imperative package management. Witness manifest files on the old BSD pkg system. Rather than every package maintainer writing an install/deinstall script to invoke the relevant account database tools, packages place a @newuser or @newgroup directive in the file and the packaging system handles creating and deleting the account at appropriate times. * https://man.openbsd.org/pkg_create.1 https://man.openbsd.org/pkg_create.1

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 ago
If 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 ago
  That'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.

jack9 8y ago

> systemd's job is to start daemons But that's not all it does and the dependencies of systemd alongside making systemd a dependency, results in a very different observable reality.

jhoechtl 8y ago

And do the logging. My only gripe is that it logs in a binary format requiring special tools to read the logs. Otherwise systemd is a marvel.

lomnakkus 8y ago

Personally, I think even having to choose a UID at install time or dynamically is a pretty sad indictment of just how broken the user system on Linux (and pretty much every UNIX-like) is. It leads to a huge amount of incidental complexity where there's a much simpler way: User IDs should just be randomly chosen UUIDs -- either generated by upstreams or by the distros. Any metadata attached to the user UID could just be preinstalled for all possible daemons[0] -- and it should be separate from the mutable /etc/passwd stuff. Obviously there's so much inertia in the existing system that it could realistically never happen at this point, but one can dream, right? [0] Kind of like e.g. /etc/services but with UUIDs.

fowl2 8y ago
Except of course if you want multiple instances of the same daemon
- lomnakkus 8y ago
  Um, mix in a second randomly-chosen UUID? My point wasn't so much that I had the perfect solution and that I'd thought of everything. It's that there are much better systems and that we should actually strive to get there.
JdeBP 8y ago
One can, and many people have, over the years. Some of the more interesting ideas that people have had, in my view, have been: * ID systems that introduce hierarchies, allowing (say) a user to create multiple sub-users (one for running the WWW browser, one for running the office suite, one for running the chat program, ...); * proper nonce ID creation with segregation guarantees (c.f. nonce SIDs in the Windows NT world); and * IDs that are reference counted, accessible via descriptors, passable from process to process via descriptor-passing mechanisms, and explicitly supplied in system calls for opening/creating things.

JdeBP 8y ago

Actually, wanting this stuff not at install/configure time is one of the primary driving forces behind the mechanism. Lennart Poettering notes that it moves the relevant tasks out of package pre/post-install/deinstall scripts and into service startup and shutdown. Ironically, the alternative approach here is more descriptive and less imperative package management. Witness manifest files on the old BSD pkg system. Rather than every package maintainer writing an install/deinstall script to invoke the relevant account database tools, packages place a @newuser or @newgroup directive in the file and the packaging system handles creating and deleting the account at appropriate times. * https://man.openbsd.org/pkg_create.1 https://man.openbsd.org/pkg_create.1