Using FDSTORE=1 to store an accepted TCP socket

[eriksjolund]

Is it possible to use FDSTORE=1 (see man sd_notify) to store an accepted TCP socket from a containerized server?
I started to investigate this. Here is a minimal example

https://github.com/eriksjolund/systemd-restart-service-fdstore

where a server stores an accepted TCP socket with FDSTORE=1 the first time the server is started.
The server talks to a client but every nth time it receives a string from the client, the server will call exit(EXIT_FAILURE).
systemd notices the failure and starts the server again, but now systemd also passes in the previously stored
accepted TCP socket file descriptor.

The client will not notice the restart because the TCP connection is not closed.

The example server worked when running it directly on the host! The next thing to try out is running the server from a container with Podman. Let's see how that goes. A first test didn't succeed, so some more testing is needed.

[eriksjolund]

The function

int sd_pid_notify_with_fds( pid_t pid,
	int unset_environment,
	const char *state,
	const int *fds,
	unsigned n_fds);

(see man sd_notify) sends the file descriptors with SCM_RIGHTS and sendmsg() (see man unix).

conmon doesn't handle such messages (see conn_sock.c).

It looks like passing an accepted TCP socket from a container process to systemd running on the host is not possible with the current podman/conmon implementation. (I would guess that such functionality is not expected by any specification/standard so this is not a bug)

[rhatdan]

@giuseppe @haircommander PTAL

[eriksjolund]

@rhatdan maybe in the future when I know more how it works. Right now I haven't done any proper patch. It was a more of a test to see if it was at all possible. If there is anyone else who want to write a patch, feel free to do it.

By the way, shouldn't conmon proxy all notification messages to systemd (with the exception of MAINPID=)?
Then for instance status messages STATUS= could be displayed by systemd (and also podman).

A cool feature that could come out of passing FDs from the container to systemd: Being able to to upgrade a container while a client is connected to the containerized server: #13348 (comment)

SELinux

Regarding audit2allow, yes you're right, I forgot to label the conmon executable.

type=AVC msg=audit(1648322211.396:1957): avc:  denied  { entrypoint } for  pid=742056 comm="podman" path="/home/esjolund/can_be_deleted/conmon/bin/conmon" dev="nvme0n1p2" ino=538208603 scontext=unconfined_u:system_r:container_runtime_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=1

[esjolund@asus ~]$ ls -lZ ~/can_be_deleted/conmon/bin/conmon 
-rwxr-xr-x. 1 esjolund esjolund unconfined_u:object_r:default_t:s0 169168 Mar 26 21:10 /home/esjolund/can_be_deleted/conmon/bin/conmon
[esjolund@asus ~]$ 

[eriksjolund]

I see there is already an issue about adding support for STATUS= containers/conmon#311

[giuseppe]

I am not sure if we want to expose all the systemd-notify features in our tools, since some of them are visible from the host. Could FDSTORE be abused from a container to circumvent its open file descriptors limits?

[eriksjolund]

The service would only be able to store FileDescriptorStoreMax file descriptors
https://www.freedesktop.org/software/systemd/man/systemd.service.html#FileDescriptorStoreMax=
and conmon would be able to count them as they pass by.
conmon could also decide which file descriptors to let through. Maybe it could be configurable what type of systemd-notify features to allow?