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..