Marcus Rueckert wrote:
On 2003-03-19 20:30:53 -0500, Charlie Brady wrote:
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?
You'll see that in the setup I've detailed above I am only using the "imap" binary from dovecot. I'm happy with the division of labour which has tcpserver doing network connection control, imapfront-auth+cvm doing authentication and uid switching, and imap doing mailbox access and IMAp protocol implementation. I expect to add stunnel doing TLS to that mix tomorrow.
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.
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".
hi first of all i want to paste this
On Wed, 19 Mar 2003, Timo Sirainen wrote: ( Message-Id: 1048083821.850.30.camel@hurina )
Only solution for now is to set /var/mail world-writable and sticky. Another way would be to use more privileged process for handling lock files. Some programs use setuid or setgid binary for that. I was thinking that I'd let imap process request the locks from master process. That would also allow overriding stale lock files created by other users with shared mailboxes.
another point would be no reusing. you restart all processes on each connection. if i count correctly:
1 tcpserver + 1 imapauth + 1 imap binary per connection
forked on every connect.
iirc correctly cras implemented resuing of the already spawned processes. maybe a reason.
tcpserver has been used in the high-performance mail system, Qmail. It really doesn't suffer as high an overhead as you think. Three processes are not spawned, instead each one is replaced by the next in the same process space (using execv or execvp). tcpserver either rejects the connection (based upon connecting IP rules), or adds specified variables to the environment and execs the next program in the chain. imapauth negotiates login, fails or execs imap. This kind of exec chaining has shown to be really efficient on unix/linux platforms.
Gary