Aren't systemd's security capabilities in userspace simpler to use?

> Private keys. Sensitive configuration files. Filesystem initializations.

For the filesystem initialization bit you could potentially use a different process. Systemd has a system-wide filesystem initialization service that runs on boot, which it uses to initialize some of its services' filesystem paths, and other services can drop in a config file if they choose to do setup this way.

> It's not only about having read access to specific resources, but often times initializing those resources, or even re-initializing after failure. Any complex program will either need to manage dropping capabilities on its own, or it will have to be architected as a collection of multiple independent processes invoked separately. In such cases, systemd doesn't simplify things; it complicates them.

You can still have your service do its own capability dropping, systemd isn't forcing you to use its capability dropping mechanism, so it can't be complicating matters here.

If you *do* choose to split your service up, then I think systemd unit files are simpler, though if you disagree nobody is stopping you using an old sysv init script.

> Socket activation existed for decades before systemd in the form of inetd, and almost nobody bothered to use it. Why? Because opening a socket is but one of many ad hoc initialization tasks complex services implement. Instead of trying to abstract away these patterns and trying to provide a One True Interface only suitable for imaginary or proof-of-concept programs, it makes more sense to provide a simple, powerful primitive which takes care of 80% of the work, leaving the finer ad hoc details to the application. fork is like this. tame tries to be like this, but only time will tell whether how useful it really is.

As a counter-point, I've repeatedly been frustrated by services that insist on doing their own socket initialization, and are insufficiently flexible about what I need to do with the sockets.
Usually binding it to an ephemeral port, so I can start up the service multiple times, to run isolated tests against the service in parallel, or binding the service to a specific interface, so I'm not relying on binding to the IP address that the interface I want to bind it to happens to currently have.

> The problem with systemd is that it makes easy things easier, but complex things more convoluted, assuming it's useful at all.

I don't understand your point, since as far as I'm aware it's not preventing you doing it the old way.

> systemd isn't _composable_ in the sense of being able to build another layer atop it.

I don't follow.

The rkt guys are building container management on top of systemd-nspawn and service management.
As I understand it, desktop environment developers are building on top of systemd-logind's session management.
The Cockpit guys are building server administration interfaces on top of systemd's APIs.

> It's a tool for system administrators wrangling poorly written software.

You've described most software there, aren't tools for dealing with it valuable?

> It's not a solution for implementing correctly written software in the first instance. Likewise for something like journald. It's a nice piece of engineering. But it's not composable.

Given your previous definition of composable software being something you can build on, then I think it is, as rsyslog builds on journald to provide the traditional interface on top of journald by reading messages out of the journal.

> A composable logging approach would be logging to stderr on a file descriptor specifiable via the invocation options, so that users can direct log messages however and where ever they see fit,

How is this standard interface for providing logging descriptors to processes composable, but setting up other resources like sockets not?

> including but not limited to journald.

Indeed. journald gives you the option of setting up an extra file descriptor, which messages written to get appropriately labelled.

The application or an ancestor program can set this up with sd_journal_stream_fd(), or from a shell you can do:

my_command --log-fd=100 100> >(systemd-cat --identifier=my_command_log)

> Composability allows you to programmatically extend and repurpose the functionality, without having to know about the internal details of the implementation, and without needing the cooperation of the implementation beyond the simple interface it provides--logging to a specified file descriptor.

Systemd isn't stopping you doing that.

> journald and how-to-properly-implement-logging-in-your-application are unrelated from a programmer's perspective, yet sadly conflated by system administrators and developers alike.

Are you saying neither system administrators or developers are programmers

The right way to handle private keys is to have a separated process that handle cryptography for the main application over a pipe with private keys loaded via separated programs over another pipe. This way the crypto process would not need any file system access and the main application would not need to access private keys. It is interesting that recent OpenSSHD comes rather close to this model with sshd gaining ability to use host keys stored in ssh-sgent. I wrote "almost" as ssh-agent has to create its unix socket requiring minimal filesystem access rather accepting it on stdin.

> Sensitive configuration files.

It is better to have a unix socket in the application where administrator or scripts can send those config files. This also eliminates the need for any signals and races when the application has to be notified about changes in the files.

> Filesystem initializations.

Why not to have a separated process that does this?

In any case, I think the main purpose of tame is to add *quickly* another layer of security to existing codebase. But I am not convinced that in the long term this a right approach.