Best practice for milter sockets in postfix chroot

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Best practice for milter sockets in postfix chroot

David Bürgin
I’m revisiting an opendkim milter setup I have running locally. Is there
some kind of ‘best practice’ regarding where milter sockets are placed
inside a Postfix chroot in /var/spool/postfix, and with what
permissions?

I see no /run directory being created by default in the chroot, but I
see two directories /public and /private that contain socket files. What
are these directories for? My socket is being created by an unprivileged
user, so the solution I have working so far is to create a top-level
directory /opendkim belonging to that user, and just put the socket in
there.

Thank you for any insights.


--
David
Reply | Threaded
Open this post in threaded view
|

Re: Best practice for milter sockets in postfix chroot

Wietse Venema
David B?rgin:
> I?m revisiting an opendkim milter setup I have running locally. Is there
> some kind of ?best practice? regarding where milter sockets are placed
> inside a Postfix chroot in /var/spool/postfix, and with what
> permissions?

I use TCP sockets. Those should be unreachable from outside
of the server.

non_smtpd_milters = inet:127.0.0.1:9998
smtpd_milters = inet:127.0.0.1:9998

> I see no /run directory being created by default in the chroot, but I
> see two directories /public and /private that contain socket files. What
> are these directories for?

These directories are created for communication between Postfix programs.

> My socket is being created by an unprivileged
> user, so the solution I have working so far is to create a top-level
> directory /opendkim belonging to that user, and just put the socket in
> there.

I don't like the idea of having 'other' users inside the chroot jail
(I also oppose non-Postfix programs running with 'postfix' privileges).

We will have to live with lib and etc directories to satisfy Linux
library dependencies, but those should be root-only writable so
that is safe.

Try using TCP sockets instead.

        Wietse