[dovecot] 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 Wednesday, February 26, 2003 9:58 AM +0100 Farkas Levente <lfarkas@bnap.hu> wrote:
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:-)
Services that get heavily used can push inetd to its limits - or beyond. :-)
Standalone is normally better in this case, with sendmail being a common example.
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
I don't think this will work for tcpserver. :-)
One advantage to using something sitting before the daemon is that you can depend on the other software for certain functionality and keep the daemon simple.
I suppose xinetd and tcpwrappers would do the job, or djb's tcpserver. It just depends upon which flavor you like. :-)
I'm coming to have more and more respect for djb's software, although there are still some things that make me shake my head. hehe
One disadvantage to running daemons standalone is that they if they die, they stay that way. djb's daemontools can help there.
On Wed, 26 Feb 2003, Stuart Krivis wrote:
--On Wednesday, February 26, 2003 9:58 AM +0100 Farkas Levente <lfarkas@bnap.hu> wrote:
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:-)
Services that get heavily used can push inetd to its limits - or beyond. :-)
So avoid inetd. tcpserver does the job very well.
Standalone is normally better in this case, with sendmail being a common example.
sendmail is not such a good example to quote for anything, especially this week.
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
I don't think this will work for tcpserver. :-)
No, but a run script for using tcpserver would be something like:
#! /bin/sh
exec 2>&1
exec tcpserver
-c 100
-u 0 -g 0
-l 0
-HDRP
0 143
/usr/local/libexec/dovecot/imap-login
One advantage to using something sitting before the daemon is that you can depend on the other software for certain functionality and keep the daemon simple.
Yep.
-- Charlie
On Thu, 2003-03-06 at 00:14, Charlie Brady wrote:
No, but a run script for using tcpserver would be something like:
#! /bin/sh exec 2>&1 exec tcpserver
-c 100
-u 0 -g 0
-l 0
-HDRP
0 143
/usr/local/libexec/dovecot/imap-login
Anyone want to try this? CVS has now support for inetd at least. I've tested that this works:
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 pop3 stream tcp nowait root /usr/sbin/tcpd /usr/local/libexec/dovecot/pop3-login pop3s stream tcp nowait root /usr/sbin/tcpd /usr/local/libexec/dovecot/pop3-login --ssl
There's also optional --group parameter to specify which one of the "login = xx" sections in config file to use. Hmm. Maybe I should add parameter to specify path for config file as well..
Timo,
I've written passdb and userdb modules for PostgreSQL. My C skills aren't that great, so I borrowed heavily from the LDAP modules, and I've never developed with automake/autoconf before, so I don't know how acceptable my patch to configure.in is. Anyway, it seems to work ok but I haven't done really heavy testing. If you can get past my poor C skills, I hope you will at least find my work useful as a base to expand from.
The patch supports arbitrary queries which can use the %h/%n/%d macros, so there's no need to have specific table or field names. For example, in the configuration file, you'd specify something like:
password_query = select password from users where userid = '%u'
Like the LDAP module, it supports PLAIN, PLAIN-MD5, DIGEST-MD5, and CRYPT. It also tries to be secure by immediately rejecting any auth attempts that don't fit a very strict format. If the user-provided data contains any non-standard characters, the query returns more than one row, etc., auth will immediately fail.
Are you interested in my patch, and if so, how should I send it? Does the list accept attachments? (The patch is against current CVS, by the way.)
Regards,
-- Alex Howansky Wankwood Associates http://www.wankwood.com/
On Thu, 2003-03-06 at 21:31, Alex Howansky wrote:
I've written passdb and userdb modules for PostgreSQL. My C skills aren't that great, so I borrowed heavily from the LDAP modules, and I've never developed with automake/autoconf before, so I don't know how acceptable my patch to configure.in is. Anyway, it seems to work ok but I haven't done really heavy testing. If you can get past my poor C skills, I hope you will at least find my work useful as a base to expand from.
My plans for SQL support was to create a simple SQL wrapper library so that there wouldn't have to be multiple separate authentication modules for different SQL databases. The same library could be used also by SQL mail database code once I get around writing that.
But since I haven't managed to write either one yet, I could include separate pgsql auth module for now. And I'd guess that code could be later just modified to use the SQL library instead of direct pgsql calls and renamed to be generic SQL auth module.
Are you interested in my patch, and if so, how should I send it? Does the list accept attachments? (The patch is against current CVS, by the way.)
List accepts attachments, but I'm not sure if anyone else here but me cares about it :) So "cvs diff -u" and mail it to me.
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_CHARS= export 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
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.
isnt there a lib offering tcp-server like functionality?
just my pi cents darix
-- irssi - the client of the smart and beautiful people
http://www.irssi.de/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
On Thu, 2003-03-20 at 14:51, GARY GENDEL wrote:
iirc correctly cras implemented resuing of the already spawned processes. maybe a reason.
No, I don't reuse processes. They could be reused within same UID, but I'm not sure if it's good idea. At least if the UID is used by multiple users, something sensitive could be left in process memory space from previous user and that's not really good.
I've actually been thinking that I could make imap process completely non-blocking which would allow using one process for multiple IMAP connections for same user. The problem cases are mostly just APPEND which blocks for input from user, and the commands which return a lot of data and block on output. After fixing those, there's still the problem that at least SEARCH could block because it's so slow. Maybe have two processes, one handling slow/large queries, other handling quick queries.
Well, there's still the annoying problem that by making the output non-blocking, I'd have to be constantly calling poll() to see when I can write more data. That's a lot of useless syscalls compared to the current blocking model.
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.
It also has the problem that it has to run as root until user has authenticated.
Dovecot can also be setup to use a single process to handle multiple login connections. That means only a single fork+exec per connection, and still never parsing user input as root.
[Please remember to trim down to minimum quoted text, guys]
On Thu, 20 Mar 2003, Marcus Rueckert wrote:
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".
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.
You haven't said why you wanted to paste that. Could you explain please?
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.
You haven't counted correct, as someone has already pointed out (and as indeed I did in the text you have quoted above).
iirc correctly cras implemented resuing of the already spawned processes. maybe a reason.
I had to use google to find out what "cras" was. ["cras" is Timo.]
isnt there a lib offering tcp-server like functionality?
Probably not, but I don't see the relevance anyway.
-- Charlie
On Thu, 2003-03-20 at 03:30, Charlie Brady wrote:
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/).
002 login foo xxxxx
- PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED] Logged in as foo
There's one problem. Dovecot shouldn't reply with PREAUTH but "002 OK". Mailfront gives the 002 in environment variable, so you'd have to modify Dovecot to use it. Dovecot did before use such variable, but I changed it later to send the OK before executing imap process. I don't really remember why anymore, but I think there was a good reason :)
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?
Not really. And I'm not really sure how I could get it more detailed? :) I think that tells the most relevant things.
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.
Well, your setup doesn't have privilege separation :) It runs as root all the way until imap process is started. I looked at mailfront and it looked good, but I wouldn't be that confident after you add SSL support. There's been holes in OpenSSL library, and I think there's still more to be found (or created). Security holes in it gives instant root access with your setup, with Dovecot setup the process executing SSL is non-privileged and chrooted so it's not very likely that attacker could do much there.
Another problem with mailfront is that it doesn't support IMAP literals, eg.:
x login {4} user {4} pass
I don't know if there's any clients that would do it, but it would be valid for them.
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".
I implemented this now so that imap-login executes, which forks a new master process. imap-login dies after user logs in, but master stays there. imap process is also forked by master process.
On 20 Mar 2003, Timo Sirainen wrote:
On Thu, 2003-03-20 at 03:30, Charlie Brady wrote:
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/).
002 login foo xxxxx
- PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED] Logged in as foo
There's one problem. Dovecot shouldn't reply with PREAUTH but "002 OK". Mailfront gives the 002 in environment variable, so you'd have to modify Dovecot to use it.
I realised that was a problem. I'm happy to hear that you have a solution :-)
Dovecot did before use such variable, but I changed it later to send the OK before executing imap process. I don't really remember why anymore, but I think there was a good reason :)
Perhaps the reason is to be found in CVS change logs.
I'd really appreciate it if you could point out to me where I'd find the code which would make use of the variable.
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?
Not really. And I'm not really sure how I could get it more detailed? :) I think that tells the most relevant things.
I guess I asked the wrong question. I shouldn't have asked "how" - I should have asked "why have you done it that way?". The system you have seems over complex. Simple solutions (if they work correctly) are always better.
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.
Well, your setup doesn't have privilege separation :) It runs as root all the way until imap process is started. I looked at mailfront and it looked good, but I wouldn't be that confident after you add SSL support. There's been holes in OpenSSL library, and I think there's still more to be found (or created). Security holes in it gives instant root access with your setup,
Not so. See below.
with Dovecot setup the process executing SSL is non-privileged and chrooted so it's not very likely that attacker could do much there.
If you have a look at Scott Gifford's work, he also runs SSL non-root and chrooted. I agree with you that that is a very significant improvement over established practice.
Another problem with mailfront is that it doesn't support IMAP literals, eg.:
x login {4} user {4} pass
I don't know if there's any clients that would do it, but it would be valid for them.
Yes, that is a deficiency, but as you point out, probably not practically relevant at the moment. If it did become a problem, mailfront could be patched - it's GPL software, and Bruce Guenter can be persuaded to do commissioned work.
-- Charlie
On Thu, 20 Mar 2003, Charlie Brady wrote:
On 20 Mar 2003, Timo Sirainen wrote:
Dovecot did before use such variable, but I changed it later to send the OK before executing imap process. I don't really remember why anymore, but I think there was a good reason :)
Perhaps the reason is to be found in CVS change logs.
I'd really appreciate it if you could point out to me where I'd find the code which would make use of the variable.
Found it. Here's the change which broke mailfront compatibility: revision 1.20 date: 2003/01/27 01:33:40; author: cras; state: Exp; lines: +4 -5 We have now separate "userdb" and "passdb". They aren't tied to each others in any way, so it's possible to use whatever user database with whatever password database. Added "static" userdb, which uses same uid/gid for everyone and generates home directory from given template. This could be useful with PAM, although insecure since everyone uses same uid. Not too well tested, and userdb/passdb API still needs to be changed to asynchronous for sql/ldap/etc lookups. diff -u -r1.19 -r1.20 --- src/imap/main.c 5 Jan 2003 13:09:51 -0000 1.19 +++ src/imap/main.c 27 Jan 2003 01:33:40 -0000 1.20 @@ -12,7 +12,7 @@ #include <syslog.h> #define IS_STANDALONE() \ - (getenv("LOGIN_TAG") == NULL) + (getenv("LOGGED_IN") == NULL) struct ioloop *ioloop; static char log_prefix[128]; /* syslog() needs this to be permanent */ @@ -104,9 +104,6 @@ client_send_line(client, t_strconcat( "* PREAUTH [CAPABILITY "CAPABILITY_STRING"] " "Logged in as ", getenv("USER"), NULL)); - } else { - client_send_line(client, t_strconcat(getenv("LOGIN_TAG"), - " OK Logged in.", NULL)); } } @@ -125,8 +122,10 @@ int main(int argc __attr_unused__, char *argv[], char *envp[]) { #ifdef DEBUG - if (getenv("LOGIN_TAG") != NULL) + if (getenv("LOGGED_IN") != NULL) { fd_debug_verify_leaks(3, 1024); + putenv("DISABLE_ALARMHUP=1"); /* annoying when debugging */ + } #endif /* NOTE: we start rooted, so keep the code minimal until restrict_access_by_env() is called */ -- Charlie
On Thu, 2003-03-20 at 17:27, 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?
Not really. And I'm not really sure how I could get it more detailed? :) I think that tells the most relevant things.
I guess I asked the wrong question. I shouldn't have asked "how" - I should have asked "why have you done it that way?". The system you have seems over complex. Simple solutions (if they work correctly) are always better.
It's mostly about running things with least required privileges. I don't think it's really complex either, only thing that makes it more complex is IPC.
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.
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?
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.
-- Charlie
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.
On 20 Mar 2003, Timo Sirainen wrote:
On Thu, 2003-03-20 at 21:05, Charlie Brady wrote:
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.
You need two processes per connection or you don't have adequate privilege separation. In my case, I have one acting either as a cleartext proxy or as an SSL wrapper, and the other does authentication and then execs the imap daemon. How would you avoid one
It also does SSL initialization only once, instead of once per connection. Sure, this could also be done by separate long running SSL process.
Yes, it would be nice to do SSL initialization once, but I don't think the performance issue is enough to compomise the security and reliabilty of the system for.
Anyway, I don't really care much about it since it pretty much means that exploiting it gives access to connections of all users.
So you don't want to have a long running login process after all?
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?
I don't know, but I'm trying to learn. You know your design and your code;
I'm just feeling my way around. Your documentation is good in parts, but
there are still big gaps. The installation documentation only covers
building - I have yet to find anything which tells me how to execute
dovecot (have I missed it?). I'm not sure which processes run when, and
exactly what communication occurs between them over what communication
channels.
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.
I don't know exactly what "sent it through master process" means.
I have a preference for running simple software which I already have reason to trust. This is why I want to use tcpserver, and why I have a leaning towards using mailfront and cvm. I know that stunnel isn't completely wonderful, but it is very widely used, and the chroot feature added by Scott Gifford fixes the principal weakness.
I am looking for a better IMAP daemon than I have at present, but I would prefer not to have a new system of authentication, and a new network connection monitor. There is a lot of new (to me) code in dovecot, but the only code of high value to me is the imap daemon itself.
I hope this explains my line of questioning to you a little.
-- Charlie
On Thu, 2003-03-20 at 23:27, Charlie Brady wrote:
Anyway, I don't really care much about it since it pretty much means that exploiting it gives access to connections of all users.
So you don't want to have a long running login process after all?
I don't, but I give option if someone else does who cares more about performance than security.
I don't know, but I'm trying to learn. You know your design and your code;
I'm just feeling my way around. Your documentation is good in parts, but there are still big gaps. The installation documentation only covers building - I have yet to find anything which tells me how to execute dovecot (have I missed it?). I'm not sure which processes run when, and exactly what communication occurs between them over what communication channels.
It's executed by running "dovecot" :) INSTALL document actually still says imap-master, fixing..
dovecot process anyway executes everything else. They talk to each others only with UNIX sockets.
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.
I don't know exactly what "sent it through master process" means.
File descriptor passing through UNIX socket. Login process accept()s the new socket and handles everything until client has successfully logged in, after that the socket is passed to master process and closed. Master process executes new imap process and sets the socket as it's stdin/stdout.
I have a preference for running simple software which I already have reason to trust. This is why I want to use tcpserver, and why I have a leaning towards using mailfront and cvm. I know that stunnel isn't completely wonderful, but it is very widely used, and the chroot feature added by Scott Gifford fixes the principal weakness.
Actually Dovecot's SSL tunnel seems to be somewhat broken now.
I am looking for a better IMAP daemon than I have at present, but I would prefer not to have a new system of authentication, and a new network connection monitor. There is a lot of new (to me) code in dovecot, but the only code of high value to me is the imap daemon itself.
OK, currently there's no reason why you shouldn't do that. I'll probably add some communication with dovecot master process <-> imap process later, but that will be optional as well. At least for requesting lock files (shared folders or mboxes in /var/mail), maybe something else..
On 20 Mar 2003, Timo Sirainen wrote:
On Thu, 2003-03-20 at 03:30, Charlie Brady wrote:
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/).
002 login foo xxxxx
- PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED] Logged in as foo
There's one problem. Dovecot shouldn't reply with PREAUTH but "002 OK". Mailfront gives the 002 in environment variable, so you'd have to modify Dovecot to use it.
Done - patch is attached.
Here is the run file for running stunnel/mailfront/dovecot under tcpserver:
#!/bin/sh
concurrency=20 ulimitdata=3000000 CVM_SASL_PLAIN=cvm-local:/tmp/.cvm-unix-local export CVM_SASL_PLAIN CVM_ACCOUNT_SPLIT_CHARS= export CVM_ACCOUNT_SPLIT_CHARS
SSLUID=id -u stunnel
SSLGID=id -g stunnel
exec 2>&1
exec
softlimit -m $ulimitdata
tcpserver -dHRvX
-c "$concurrency"
-x tcp.cdb
0 imap
makesock
stunnel -D debug -/ ssl -s "$SSLUID" -g "$SSLGID"
-N imap
-i -R seed -p imapd.pem -n imap- -f -F 3
-makesock_connect_to
/usr/bin/imapfront-auth
/usr/libexec/dovecot/imap
This is the chroot jail required by stunnel:
-rw-r----- 1 root stunnel ... ssl/imapd.pem -rw------- 1 stunnel stunnel ... ssl/seed -rw-r--r-- 1 root root ... ssl/usr/share/ssl/openssl.cnf
-- Charlie
participants (7)
-
Alex Howansky
-
Charlie Brady
-
Farkas Levente
-
GARY GENDEL
-
Marcus Rueckert
-
Stuart Krivis
-
Timo Sirainen