Support for FD passing / socket activation (systemd and others)

[VannTen]

Is your feature request motivated by a concrete problem? Please describe.

I'm trying to use https://github.com/ogarcia/rockpass (based on Rocket) on my server.
To increase the level of isolation proposed by this project, I wanted to run it in a private network namespace, using socket activation to cross the boundary. (systemd.exec see 'PrivateNetwork').
This would work by letting systemd manage the socket / port binding, and passing the fd to the process.
Instead I currently use systemd-socket-proxyd, which basically do a poor man socket activation on services not supporting it. It works, but with race conditions happening on the first request.

To correctly support that use case, Rocket would have to be able to listen on a file descriptor passed by a parent process (typically, systemd, inetd, s6) instead of binding by itself on a port or socket.

Why this feature can't or shouldn't live outside of Rocket

I'm not sure.
I have a very limited understanding of the scope of Rocket, but from reading some other issues PRs (see context), this sounds like something which is a bit difficult to plug-in.
Open to alternatives solutions I haven't think of.

Ideal Solution

Use https://github.com/Kixunil/systemd_socket
If I get the documentation right, this allows to to pass something like "systemd://socket_name" as the bind address and be done with it.

Alternatives Considered

However, the interface would be specific to systemd, which might be a bad thing. An explicit configuration might be a better option (gives an explicit fd number to use), together with https://doc.rust-lang.org/std/net/struct.TcpListener.html#impl-From%3COwnedFd%3E-for-TcpListener ?

Potential problems

• I've no idea how this would interact with things like TLS, but this could be a problem.

Additional Context

I think the following issues are relevant:

• Support for listening on Unix sockets #545 This is similar, but not quite the same thing (in this case, the Rocket server create the socket, right ?)
• Provide a lower-level connection interface #1070 This one would allow to plug-in that feature, if I understand things right (a custom listeners could use a file descriptor, right ?)

The setup which prompted this, if anyone wants to look

Caddyfile

# I use Caddy for automatic https.
#
# https://caddyserver.com/docs/caddyfile
#
# https://caddyserver.com/docs/caddyfile/concepts#addresses
{
	admin off
}

https://lesspass.my.domain {
    route {
	@rockpass {
		path /auth*
		path /passwords*
	}
	reverse_proxy @rockpass unix//run/proxy-to-rockpass
    respond 404
    }
}

# /usr/lib/systemd/system/rockpass.service
[Unit]
Description=A small and ultrasecure Lesspass database server written in Rust
Documentation=https://github.com/ogarcia/rockpass/blob/master/README.md
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
DynamicUser=yes
StateDirectory=rockpass
ExecStart=/usr/bin/rockpass
Environment=ROCKPASS_PORT=8000
PrivateNetwork=true

# [email protected]
[Unit]
Requires=%N.socket %i.service
After=%N.socket %i.service
JoinsNamespaceOf=%i.service

[Service]
ExecStart=/usr/lib/systemd/systemd-socket-proxyd 127.0.0.1:8000 # This is inside the net namespace of rockpass
PrivateTmp=yes
PrivateNetwork=yes

[Install]
WantedBy=multi-user.target

# /[email protected]
[Socket]
ListenStream=%t/proxy-to-%i

[Install]
WantedBy=sockets.target

[SergioBenitez]

I believe this would be covered by #1070. If we could pass a TcpListener directly to Rocket, instead of Rocket requiring that it be the creator, that would enable this use-case without any systemd specific effort. I think this is something we should prioritize for 0.6, so I'll milestone that issue. I'll close this one as a result.