[Dovecot] Permission denied

Timo Sirainen tss at iki.fi
Sun Jul 13 15:27:54 EEST 2003


On Sun, 2003-07-13 at 04:16, Matthias Andree wrote:
> > Anyway, home directory isn't required information from auth process. I
> > think I'll chdir to /tmp if it isn't given.
> 
> I wonder if core dumps (if any) of an authenticator process belong in
> /tmp -- /tmp is anarchy area and must be treated with care. umask(077)
> is the minimum to make sure no other user can harvest passwords from the
> core file.

No, I meant the auth process tells user's uid, gid, home directory
and/or mail location to master process. So home directory isn't required
information there. If it's not given, we should still chdir() to
somewhere else than where master is running, $prefix/var/run/dovecot/
which is 0700 root owned.

> >> Make sure you don't add ANY branches between the seteuid() calls, no
> >> mistakes must happen there.
> >
> > Why? I don't see how dropped privileges can cause much problems.
> 
> seteuid doesn't drop privileges, but temporarily puts them aside, while
> the real and saved user ID remain zero. seteuid(0) restores root
> permissions if you had them, and is a standard procedure in escalating
> privileges after a break-in.

Yes, so why is it worse to add any branches running with temporarily
dropped privileges than running with full privileges? Or are you
thinking that some geteuid() call then doesn't return 0 and thinks it's
not running as root?

I have anyway some checks that processes can't accidentally be started
as root:

	/* verify that we actually dropped the privileges */
	if (uid != 0 || disallow_root) {
		if (setuid(0) == 0)
			i_fatal("We couldn't drop root privileges");
	}

	if ((gid != 0 && uid != 0) || disallow_root) {
		if (getgid() == 0 || getegid() == 0 || setgid(0) == 0)
			i_fatal("We couldn't drop root group privileges");
	}

> The part above looks OK provided that i_fatal is simple.

Currently it is, but I'm can't be sure if someone some day adds more
complex logging functions.

> > 	} else {
> > 		/* We still have to change to some directory where we have
> > 		   rx-access. /tmp should exist everywhere. */
> > 		if (chdir("/tmp") < 0)
> > 			i_fatal("chdir(/tmp) failed: %m");
> > 	}
> 
> I don't like /tmp, see above. I'd feel more comfortable with a directory
> that only dovecot has access to, rather than /tmp.

Well, it has to be a directory where all users have at least +rx access.
+w isn't really needed. I guess I could create /var/run/dovecot/home or
something where they go, but I don't think it really matters.

Actually core dumps aren't either written by default since kernel thinks
it's running setuid-binary. You'd have to set mail_drop_priv_before_exec
= yes to allow that.




More information about the dovecot mailing list