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 write access to the keys. I have vague and not well formed concerns > that it being able to do that could be bad.
I agree it would be bad, but i'd be happy with an obnoxious warning about unnecessarily-writable keys, and not a crash. > I think a MAC system like SE Linux or Apparmor probably makes more sense as a > security measure on modern systems than using a chroot, so that's probably > not > a concern. makes sense. > It would probably cause some significant deployment friction in the short- > term, since no distros would have it (unless it's something we can include in > the package, which means something in Python, not C). > > In the near-term, I think we need to have two ways to start: one with systemd > (socket activation) and one for all other init systems. If you can give me > an > idea what the socket activation changes might look like, I can think about > how > I might integrate the two. hm, i'm looking at python3-milter -- the main issue i see is that libmilter seems to want to open the socket on its own, and i don't see a way to ask libmilter to simply use a file descriptor that you already have available :( So it's possible that this won't work without some patches to sendmail (e.g. passing an "fd:3" string to setconn()), which is a drag. Is there some pythonic milter implementation that *doesn't* link against libmilter? --dkg
signature.asc
Description: PGP signature