[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