On Thu, 2003-03-20 at 21:05, Charlie Brady wrote:
On 20 Mar 2003, Timo Sirainen wrote:
The current way also makes it possible to having long running auth and login processes. Especially long running auth process can give much higher performance since it doesn't have to keep reconnecting to LDAP or SQL server, or keep reopening and reparsing some passwd files every time a user logs in.
Why do you care about long running login processes?
That gives less amount of total running processes since you don't need extra one for handling SSL. It also does SSL initialization only once, instead of once per connection. Sure, this could also be done by separate long running SSL process.
Anyway, I don't really care much about it since it pretty much means that exploiting it gives access to connections of all users.
The long running auth process problem can be solved by using a unix domain socket. This is how Bruce Guenter's mailfront works. The authenticator runs long term, and listens to a socket (unix domain preferred, but there are other options). The login process is run from tcpserver, and gathers information from the client, and then connects to the authenticator and verified the information.
So, is it really much different from my design then? 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.