Control: forwarded 922048
https://code.launchpad.net/~dkimpy-milter-dev/dkimpy-milter/+git/dkimpy-milter/+ref/dkg/socket-activation
On Mon 2019-02-11 17:15:53 -0500, Scott Kitterman wrote:
> In the near-term, I think we need to have two ways to start: one with systemd
> (socket activation) and o
On Mon 2019-02-11 17:15:53 -0500, Scott Kitterman wrote:
> I can see advantages to this approach. I took the path I did since I was
> implementing an opendkim replacement and that's how it's done there.
>
> I think the milter would have to do something obnoxious like fail to start if
> it had wr
On Mon 2019-02-11 10:31:12 -0500, Scott Kitterman wrote:
> 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).
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
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
5 matches
Mail list logo
