The one trick I don't think that can be managed this way is that currently dkimpy-milter reads the private key files as root and then drops privileges so that it doesn't have access to the key while running (it's only in memory). Opendkim does similar, which is where I got the idea.
I'm happy to add additional functionality to integrate better with systemd, but with my upstream hat on, it needs to not be tied to systemd since it has a broader audience. I would appreciate help on this, to the extent it makes sense given the need to work on non-systemd systems. Scott K On Monday, February 11, 2019 10:08:07 AM Daniel Kahn Gillmor wrote: > Package: dkimpy-milter > Severity: wishlist > Version: 1.0.0-1 > > When running dkimpy-milter on a system that runs systemd, it would be > great to have it be socket-activated. > > This would allow dkimpy-milter to avoid needing to drop privileges > (because systemd could start the daemon with privileges already dropped) > and writing a pidfile (no need for a pidfile since systemd already > controls the cgroup), and would also ensure that no other process is > listening on the socket(s) in question, because the system manager could > open the socket(s) as pid 1 and ensure its appropriate delegation. > > We could also use systemd .socket unit FileDescriptorName= fields to > identify whether a certain file descriptor is intended to be a signing > milter or a verification milter (see sd_listen_fds(3)), if the preferred > configuration option is different sockets for different functionality. > > If you want help in making this happen, i'm happy to offer patches. > > --dkg
signature.asc
Description: This is a digitally signed message part.
