On Sun, 2007-03-11 at 09:51 -0700, Troy Engel wrote:
#login_process_per_connection = yes
...with all the notes about security ans so forth. The question is though what's a best recommended practice for efficiency and speed?
I was just updating my master/config/logging rewrite code, which has been almost-working for last two years or so. Then I had an idea:
The biggest performance problem with login_process_per_connection=yes is creating, initializing and destroying the process. login_process_per_connection=no's problem then is that the attacker can steal other users' passwords and TCP sessions (if there ever is a security hole in the login process code or in OpenSSL).
If a login process is handling only a single connection at a time that takes care of the TCP session spying/stealing. Then if all the memory allocations are always cleared before freeing the memory (or old memory when realloc()ing), that takes care of the password stealing as well, since there should be nothing important left in the memory from the previous user's session.
I can think of two potential problems: the stack and the memory allocated by libraries. Luckily OpenSSL can be told to use different memory allocation functions, and I don't think there are any other library calls made that could leave anything important into memory. As for stack, I don't think I ever store anything important there.
Benchmarks show that this works pretty nicely. I get around 1350-1400 connections/second. Using multiple connections/process gives 1450-1500 connections/second. Cleaning the memory vs. not cleaning it doesn't seem to make any noticeable performance difference.
Hmm. Except there's also Dovecot's data stack which I almost forgot. I'll add a new data_stack_clean() function to be called whenever a client is deinitialized.
The benchmarks are with the rewritten code. The same behavior can be done with v1.0 by setting login_max_connections = 1, although only CVS HEAD has the cleanup code. Looks like I can get only 1150-1200 connections with CVS HEAD both with login_max_connections=1 and with a higher value. So looks like my rewrite is actually faster even though it requires doing UNIX socket connections to log and config processes.
Oh, and as for when the rewrite is in CVS, I'm not really sure. I'm still wondering if I should put it there soon and make the release after v1.0 be v2.0, or if I should first stabilize the current new CVS HEAD features (which shouldn't take too long), do a v1.2 release and only then put this code to CVS and make it v2.0..