Hi all
For various reasons I was looking into 2.6, so I installed a copy on my
desktop. Everything works fine, except for dovecot - errors such as this
appeared in the syslog:
Jul 15 14:41:09 typhaon dovecot: Dovecot starting up
Jul 15 14:41:12 typhaon imap-login: setuid(113) failed: Resource
temporarily unavailable
Jul 15 14:41:12 typhaon dovecot: Login process died too early - shutting
down
I can imagine why setuid() should ever fail, I've confirmed that the
daemon is running as UID zero at the time it makes the call. However,
the call succeeds if I comment out:
restrict_process_size((unsigned int)-1, 1);
on line 134 of src/login-common/main.c it starts to work again.
It's very strange - I got the idea to try this from the list archives.
I'm willing to track this down if anyone can suggest possible things in
restrict_process_size() that might be causing this failure. All the
other daemons that I run that need to drop root privileges work fine..
Cheers
Grahame
--
Grahame Bowland Email: grahame at ucs.uwa.edu.au
University Communications Services Phone: +61 8 9380 1175
The University of Western Australia Fax: +61 8 9380 1109
CRICOS: 00126G
On Wed, 2003-07-16 at 08:56, Grahame Bowland wrote:> I can imagine why setuid() should ever fail, I've confirmed that the > daemon is running as UID zero at the time it makes the call. However, > the call succeeds if I comment out: > restrict_process_size((unsigned int)-1, 1); > on line 134 of src/login-common/main.c it starts to work again.Has anyone tried if 0.99.10 works by default with openwall and grsec kernels where it used to have problems? I changed this from 0 to 1 some time ago when someone said it still didn't work. Maybe I should make this configurable from config file. The whole point of it is to prevent login processes from forking, but there doesn't seem to be any good way to do that. The "1" there specifies the maximum number of processes for the whole user, not the maximum child processes for this one..
On Wed, 2003-07-16 at 08:56, Grahame Bowland wrote:> I can imagine why setuid() should ever fail, I've confirmed that the > daemon is running as UID zero at the time it makes the call. However, > the call succeeds if I comment out: > restrict_process_size((unsigned int)-1, 1); > on line 134 of src/login-common/main.c it starts to work again.How about if it was done after setuid()? :) With a few tests it looks like Linux 2.4 and OpenBSD are happy with that. diff -u -r1.11 main.c --- src/login-common/main.c 19 Jun 2003 02:00:25 -0000 1.11 +++ src/login-common/main.c 16 Jul 2003 06:34:39 -0000 @@ -130,9 +130,6 @@ static void drop_privileges(const char *name) { - /* make sure we can't fork() */ - restrict_process_size((unsigned int)-1, 1); - /* Log file or syslog opening probably requires roots */ open_logfile(name); @@ -143,6 +140,9 @@ /* Refuse to run as root - we should never need it and it's dangerous with SSL. */ restrict_access_by_env(TRUE); + + /* make sure we can't fork() */ + restrict_process_size((unsigned int)-1, 1); } static void main_init(void)