New sandbox features in systemd
endocode.com
endocode.com
Is there a clear, stable interface to define this layer as a separate one from the rest of systemd which would also allow for a different implementation to be leveraged by the service manager; or is this just another tightly coupled component for systemd with no regard for anything or anyone else?
For example, if you launch a container with Docker, then you might tell it to employ user namespaces as a way of isolating processes within the container from the rest of the system. This helps ensure that "root" inside the container is not really "root" outside it, and that the "nobody" user in two different containers is not actually the same user.
Systemd also gives users the ability to employ user namespaces (and other kernel features) while launching services, in this case through the --private-users flag to systemd-nspawn [1]. The article we're discussing does not describe a new systemd component, but a new set of configuration parameters for employing, in user space, some features offered by the Linux kernel. One of the new parameters is ProtectSystem=strict which launches processes with a read-only view of the file system.
It's valuable for systemd to support these facilities directly and not punt the problem to a higher level. To summarize, since systemd is the init system, exposing these features in systemd means that Linux kernel namespacing features can be employed even with very low-level system services; and they can be employed in configuration by administrators even with services that don't know how to self-sandbox to the same degree.
[1] https://www.freedesktop.org/software/systemd/man/systemd-nsp...
You can do something like ExecStart=bubblewrap foo, but that's a different syntax than systemd's native sandboxing.
The underlying clear and stable interface used to accomplish these things is the Linux kernel, and another service manager could provide the same features. Systemd has a configuration file format for expressing how to launch processes (which is what I'm describing above). Another service manager could parse and understand that format, if it wanted, in the same way that systemd supports SysV init scripts and classic ways of managing service lifecycle like "service foo restart" alongside its new command systemctl.