IP addresses should not leak in systemd.socket(5)

[anarcat]

On a host where you want to be careful about data retention (for various reasons, privacy, GDPR compliance, etc), you want to be able to control where IP addresses are logged and how long they are retained.

Very often, the simplest way to do so is simply to not log any IP addresses at all.

At the Tor project, this policy is generally to not keep client IP addresses on disk and to log with dates on a "day" granularity.

Unfortunately, systemd.socket activation makes that very difficult, if not impossible. Take, for example, this .socket file:

[Unit]
Description=rsync daemon archive (socket)

[Socket]
ListenStream=[::]:873
ListenStream=/run/rsyncd/archive.socket
Accept=true
FreeBind=true
MaxConnections=200

[Install]
WantedBy=sockets.target

and associated .service file:

[Unit]
Description=rsync daemon archive

[Service]
ExecStart=-/usr/bin/ionice -c best-effort -n 7 /usr/bin/rsync --daemon --config=/etc/rsyncd-archive.conf
StandardInput=socket
StandardError=journal
CapabilityBoundingSet=CAP_SYS_CHROOT CAP_SETUID CAP_SETGID CAP_DAC_READ_SEARCH
PrivateDevices=true
PrivateNetwork=true
ProtectHome=read-only
ProtectSystem=full

This yields the following entry in /var/log/daemon.log (or systemd's equivalent journald) when connecting from 10.0.0.1:

Jan 20 20:09:45 hostname systemd[1]: Started rsync daemon archive (10.0.0.1:35380).
Jan 20 20:09:45 hostname systemd[1]: rsyncd-archive@76504-159.69.63.226:873-10.0.0.1:35380.service: Succeeded.

I could not find a way to disable this logging in systemd.socket(5). I feel the second line might be changeable based on the service template definition, but the first line doesn't seem to be modifiable.

It's of course possible to not store logs at all in journald (Storage=none in journald.conf) or store them in RAM (default for --user but not --system), but our policy explicitly mandates to not store it at all, anywhere. What I would prefer is to have a way to turn off this identification altogether. I understand it can be problematic because the service is instantiated with the src-dest-IP-port tuple, but maybe there's some way around that as well?

Thanks!