dovecot - Feb 2003 - inetd/xinetd/tcpserver support

I was just thinking how they could be easily supported. This would work,
right? :

imap stream tcp nowait root /usr/sbin/tcpd /usr/local/libexec/dovecot/imap-login
imaps stream tcp nowait root /usr/sbin/tcpd
/usr/local/libexec/dovecot/imap-login --ssl

imap-login would try to connect to master process using some named
socket. If it couldn't, it would create the master process itself.
Master process would work as usual (executes auth and imap processes),
except it wouldn't be executing login processes.

This wouldn't require much code changing, and it would still be using
all the same privilege separations as the standalone version so it would
be just a secure.

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.

I guess I'll implement this soon and try if it works.

I always prefer standalone daemons, and as we see the tendency is that 
most server run as standalone (apache, vsftpd, ssh...). at the begining 
they has (x)inetd version later remove it...
IMHO ip/tcp filtering should have done in a firewall or some fitering 
can be implemented in the standalone server too..
but this is just my 2c:-)

Timo Sirainen wrote:
> I was just thinking how they could be easily supported. This would work,
> right? :
> 
> imap stream tcp nowait root /usr/sbin/tcpd
/usr/local/libexec/dovecot/imap-login
> imaps stream tcp nowait root /usr/sbin/tcpd
/usr/local/libexec/dovecot/imap-login --ssl
> 
> imap-login would try to connect to master process using some named
> socket. If it couldn't, it would create the master process itself.
> Master process would work as usual (executes auth and imap processes),
> except it wouldn't be executing login processes.
> 
> This wouldn't require much code changing, and it would still be using
> all the same privilege separations as the standalone version so it would
> be just a secure.
> 
> 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.
> 
> I guess I'll implement this soon and try if it works.
> 
> 
> 

-- 
   Levente                               "Si vis pacem para bellum!"

On 26 Feb 2003, Timo Sirainen wrote:
> I was just thinking how they could be easily supported. This would work,
> right? :
> 
> imap stream tcp nowait root /usr/sbin/tcpd
/usr/local/libexec/dovecot/imap-login
> imaps stream tcp nowait root /usr/sbin/tcpd
/usr/local/libexec/dovecot/imap-login --ssl
> 
> imap-login would try to connect to master process using some named
> socket. If it couldn't, it would create the master process itself.
> Master process would work as usual (executes auth and imap processes),
> except it wouldn't be executing login processes.
I have a working tcpserver system, but one using a substantially different 
process mix. I haven't used imap-login at all, but have used 
imapfront-auth from Bruce Guenter's mailfront package 
(http://www.untroubled.org/mailfront/).

Here is the run script:

#!/bin/sh

concurrency=20
ulimitdata=3000000
CVM_SASL_PLAIN=cvm-local:/tmp/.cvm-unix-local
export CVM_SASL_PLAIN
CVM_ACCOUNT_SPLIT_CHARSexport CVM_ACCOUNT_SPLIT_CHARS

exec 2>&1
exec \
  softlimit -m $ulimitdata \
  tcpserver -dHRvX \
  -c "$concurrency" \
  -x tcp.cdb \
  0 imap \
  /usr/bin/imapfront-auth \
  /usr/local/bin/imap


And here is the IMAP session:

* OK imapfront ready.
001 capability
* CAPABILITY IMAP4rev1 
001 OK CAPABILITY completed
002 login foo xxxxx
* PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND 
UNSELECT LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED] Logged in as foo
002 capability
* CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT 
LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED
002 OK Capability completed.
003 select inbox
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags 
permitted.
* 4 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1045884314] UIDs valid
* OK [UIDNEXT 5] Predicted next UID
003 OK [READ-WRITE] Select completed.
004 create abox
004 OK Create completed.
005 select abox
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags 
permitted.
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1045885867] UIDs valid
* OK [UIDNEXT 1] Predicted next UID
005 OK [READ-WRITE] Select completed.
006 list "" % 
* LIST (\UnMarked) "." "Trash"
* LIST (\UnMarked) "." "foo"
* LIST (\UnMarked) "." "onebox"
* LIST (\UnMarked) "." "abox"
* LIST (\UnMarked) "." "INBOX"
006 OK List completed.
006 list "" ""
* LIST (\Noselect) "." ""
006 OK List completed.
007 logout
* BYE Logging out
007 OK Logout completed.

This setup can't do STARTTLS, but now that I have it working in plaintext,
I can look at adapting Scott Gifford's stunnel TLS proxy work:

http://www.suspectclass.com/~sgifford/stunnel-tlsproxy/stunnel-tlsproxy.html 

I don't expect this to be too difficult.
 
> This wouldn't require much code changing, and it would still be using
> all the same privilege separations as the standalone version so it would
> be just a secure.
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". 

--
Charlie