On Thu, 2003-03-20 at 03:30, Charlie Brady wrote:
I have a working tcpserver system, but one using a substantially different process mix. I haven't used imap-login at all, but have used imapfront-auth from Bruce Guenter's mailfront package (http://www.untroubled.org/mailfront/).
002 login foo xxxxx
- PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED] Logged in as foo
There's one problem. Dovecot shouldn't reply with PREAUTH but "002 OK". Mailfront gives the 002 in environment variable, so you'd have to modify Dovecot to use it. Dovecot did before use such variable, but I changed it later to send the OK before executing imap process. I don't really remember why anymore, but I think there was a good reason :)
Privilege separation is a very good thing. Is there any more detailed documentation of how you have done yours than http://dovecot.procontrol.fi/doc/design.txt?
Not really. And I'm not really sure how I could get it more detailed? :) I think that tells the most relevant things.
Can you provide any reasons why I should use your imap-master, imap-auth and imap-login proceses rather than my mix'n'match setup? I'm confident that my setup has the simple, secure, reliable characteristics that I need, whereas I don't have the same confidence in your process set - it seems unnecessarily complex to me.
Well, your setup doesn't have privilege separation :) It runs as root all the way until imap process is started. I looked at mailfront and it looked good, but I wouldn't be that confident after you add SSL support. There's been holes in OpenSSL library, and I think there's still more to be found (or created). Security holes in it gives instant root access with your setup, with Dovecot setup the process executing SSL is non-privileged and chrooted so it's not very likely that attacker could do much there.
Another problem with mailfront is that it doesn't support IMAP literals, eg.:
x login {4} user {4} pass
I don't know if there's any clients that would do it, but it would be valid for them.
Only thing I'm wondering is if any of the TCP wrappers care about the created child processes? The master process would have to stay alive after the connection that created it dies.
In general they will, as they will do connection counting. This is handled in my setup above, as each process execs the following one: tcpserver forks, and the child execs "imapfront-auth", which then authenticates and execs "imap".
I implemented this now so that imap-login executes, which forks a new master process. imap-login dies after user logs in, but master stays there. imap process is also forked by master process.