Passing FDs through `systemd-run`, e.g. via `LISTEN_FDS`

[snarkmaster]

This works today:

exec 3> /my/file
export LISTEN_FDS=3
export LISTEN_PID=$$
exec systemd-nspawn ... -- my_program --fd 3

This is great for exposing files or sockets in the resulting container.

If I have a container running systemd inside, I can similarly try to start a program inside it via systemd-run. However, in this case, LISTEN_FDS-style file descriptor forwarding is not supported, so in this example my program will fail with EBADF.

exec 3> /my/file
export LISTEN_FDS=3
export LISTEN_PID=$$
exec systemd-run --pipe --wait ... -- my_program --fd 3

As far as I can tell, implementing this should be possible. The least bad idea I found in 30 minutes of reading the code was to add a new handler to dbus-service.c that calls service_add_fd_store.

Would this be a sensible API? Are there other good ways to run a transient unit with arbitrary FDs inside my container?

If the API is OK, what about the implementation, is it enough to sequentially add my FDs to the FD store of the transient unit?

[poettering]

We currently do not allow adding fds to the fdstore of arbitrary services. Only the service itself can do that.

[poettering]

Note that adding a D-Bus API for that is a bit racy: we will close all fds associated with a service as soon as the service is fully stopped and no further job queued for it. Thus, if you issue a D-Bus method call to upload the fds while the service is down and no job queued for it, it would just close it again right-away.

[snarkmaster]

@poettering, thanks for the quick reply. I'm reading your explanation to mean that introducing a DBus method that adds FDs to the FD store would not be a natural solution to my problem, because fdstore entries actually have lifetime semantics more complex than what a typical exec wrapper would do with FDs (i.e. nothing, just forwarding them by inheritance).

Is there a way of tackling the use-case -- starting a transient unit with specified FDs, besides 0,1,2 -- which does not run afoul of all the complexities of fdstore semantics?

I have no opinion on the implementation, but getting the outcome would be great.

In lieu of systemd-run support, I can achieve the desired result by:

• bind-mounting my own UNIX socket into the container
• bind-mounting a statically linked C fdtunnel binary that knows how to receive FDs on that socket, and exec another process
• having systemd-run invoke my fdtunnel as a wrapper for my actual payload

As you can imagine, implementing this is both messier and less transparent than systemd-run forwarding the same FDs via DBus, and systemd providing them to the process before exec.

And since systemd, being the process manager, seems like the natural place to set up FDs, I was hopeful there'd be away to support this directly.

[snarkmaster]

I worked around the lack of FD forwarding by reimplementing systemd-run-like functionality via nsenter + manual cgroup management. That affords me complete control of the FDs.