[dovecot] Re: Long running auth/login processes (was Re: Re: inetd/xinetd/tcpserver support)

[Timo Sirainen]

On Thu, 2003-03-20 at 23:27, Charlie Brady wrote:
> > Anyway, I don't really care much about it since it pretty much means
> > that exploiting it gives access to connections of all users.
> 
> So you don't want to have a long running login process after all?

I don't, but I give option if someone else does who cares more about
performance than security.

> I don't know, but I'm trying to learn. You know your design and your code;  
> I'm just feeling my way around. Your documentation is good in parts, but
> there are still big gaps. The installation documentation only covers
> building - I have yet to find anything which tells me how to execute
> dovecot (have I missed it?). I'm not sure which processes run when, and
> exactly what communication occurs between them over what communication
> channels.

It's executed by running "dovecot" :) INSTALL document actually still
says imap-master, fixing..

dovecot process anyway executes everything else. They talk to each
others only with UNIX sockets.

> > Sounds like the
> > only difference is that it runs login code as root and exec()s imap
> > binary after login, where my code sends it through master process which
> > forks new imap process.
> 
> I don't know exactly what "sent it through master process" means.

File descriptor passing through UNIX socket. Login process accept()s the
new socket and handles everything until client has successfully logged
in, after that the socket is passed to master process and closed. Master
process executes new imap process and sets the socket as it's
stdin/stdout.

> I have a preference for running simple software which I already have
> reason to trust.  This is why I want to use tcpserver, and why I have a 
> leaning towards using mailfront and cvm. I know that stunnel isn't 
> completely wonderful, but it is very widely used, and the chroot feature 
> added by Scott Gifford fixes the principal weakness.

Actually Dovecot's SSL tunnel seems to be somewhat broken now.

> I am looking for a better IMAP daemon than I have at present, but I would 
> prefer not to have a new system of authentication, and a new network 
> connection monitor. There is a lot of new (to me) code in dovecot, but the 
> only code of high value to me is the imap daemon itself.

OK, currently there's no reason why you shouldn't do that. I'll probably
add some communication with dovecot master process <-> imap process
later, but that will be optional as well. At least for requesting lock
files (shared folders or mboxes in /var/mail), maybe something else..