[dovecot] Re: inetd/xinetd/tcpserver support

[Timo Sirainen]

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.