[dovecot] Re: inetd/xinetd/tcpserver support

[GARY GENDEL]

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