4 ms·

I'm not sure if you're joking, but there are a couple of such protocols - IMAP being the most prominent. As for opensmtpd, it should probably only reject, drop

by e12e 7y ago

I'm not sure if you're joking, but there are a couple of such protocols - IMAP being the most prominent. As for opensmtpd, it should probably only reject, drop or hand off mail via LMTP. Then another daemon should deal with storage and provide access to mail. You might look at dbmail.org if you want mail storage in PostgreSQL with IMAP support, for example. Dovecot can handle incoming mail via LMTP, but needs roit to write to mailboxes, unfortunately. I suppose you could give each user a suid binary to handle incommming email... Not sure if that'd be a great idea, though. Ed: ironically, a change along these lines resulted in this bug. Maybe it would be better if opensmtpd only spoke LMTP, and never did any launching of a shell. Conceivably the LMTP daemon might have a similar bug, though..

anonsivalley652 7y ago
I wonder if instead of running a single mail delivery agent as root that can touch everything everywhere, a separate child process should run as that user and chroot/drop privs to where it can only write to mbox files and log if it can't. Or at least confine it to mbox files via SELinux, which still seems too open. Processes running as root for fs permissions reasons only is usually an ops smell that something wasn't architected or configured correctly.
- akira2501 7y ago
  I believe you're basically describing the architecture of qmail.
  - anonsivalley652 7y ago
    Not even close. Qmail is quite different in that it uses maildirs instead of mbox and does a bunch of things differently including proprietary formats. And it's under-maintained and not widely used. I was only talking about the delivery of mail, not rearchitecting the world.
- edoceo 7y ago
  For mail, they also need low ports, which typically requires root.
  - e12e 7y ago
    Not for a long time - it can be fixed via capabilities and/or via firewall rules.
- e12e 7y ago
  > separate child process should run as that user and chroot/drop privs It was spawning such a process that actually was the problem in this case. I'm still a little baffled that things could go so wrong in handling input/parameters to system()... But it did. I'm not saying you're wrong - it's just that this concrete error happened in an odd place, as a result of changing to pretty much the architecture you mention (and only for mbox file delivery).
JdeBP 7y ago
jcranmer was fairly obviously making the point that all of this has long since been invented and done and doesn't require all of the from-scratch work here in 2020 that clarry asserts. For one ironic example: Thunderbird is better at picking up local mail from a local IMAP server than it is at talking directly to a ~/Maildir/ or a ~/Mailbox .

by e12e 7y ago

anonsivalley652 7y ago

I wonder if instead of running a single mail delivery agent as root that can touch everything everywhere, a separate child process should run as that user and chroot/drop privs to where it can only write to mbox files and log if it can't. Or at least confine it to mbox files via SELinux, which still seems too open. Processes running as root for fs permissions reasons only is usually an ops smell that something wasn't architected or configured correctly.

akira2501 7y ago
I believe you're basically describing the architecture of qmail.
- anonsivalley652 7y ago
  Not even close. Qmail is quite different in that it uses maildirs instead of mbox and does a bunch of things differently including proprietary formats. And it's under-maintained and not widely used. I was only talking about the delivery of mail, not rearchitecting the world.
edoceo 7y ago
For mail, they also need low ports, which typically requires root.
- e12e 7y ago
  Not for a long time - it can be fixed via capabilities and/or via firewall rules.
e12e 7y ago
> separate child process should run as that user and chroot/drop privs It was spawning such a process that actually was the problem in this case. I'm still a little baffled that things could go so wrong in handling input/parameters to system()... But it did. I'm not saying you're wrong - it's just that this concrete error happened in an odd place, as a result of changing to pretty much the architecture you mention (and only for mbox file delivery).

JdeBP 7y ago

jcranmer was fairly obviously making the point that all of this has long since been invented and done and doesn't require all of the from-scratch work here in 2020 that clarry asserts. For one ironic example: Thunderbird is better at picking up local mail from a local IMAP server than it is at talking directly to a ~/Maildir/ or a ~/Mailbox .