[Dovecot] deliver setgid issues
Okay .. have dovecot set up with following settings :
userdb static {
args = uid=97 gid=97 home=/export/dovecot/mail/%d/%umail=mbox:/export/dovecot/mbox/%d/%u/ }
passdb passwd-file { # Path for passwd-file args = /etc/dovecot-passdb }
Passdb works I think in the sense that I can log into dovecot using a regular mail client.
The real issue is when I try to deliver any type of mail using dovecot-lda (deliver).
deliver is setuid and setgid dovecot .. I event se the static mail dirs above to be owned by dovecot (I know .. a no no .. but wanted to trace down issue)
I also have
first_valid_uid = 96
and
first_valid_uid = 96
Now .. when I try to do this ..
echo "A Test Message" | /usr/local/libexec/dovecot/deliver -d existinguser
I get this ..
master in: USER 1 echo service=deliver dovecot: Mar 11 23:45:24 Info: auth(default): master out: USER 1 echo uid=97 gid=97 home=/export/dovecot/mail//echo mail=mbox:/export/dovecot/mbox//echo/ dovecot: Mar 11 23:45:24 Error: auth(default): deliver: Fatal: setgroups(97) failed: Operation not permitted
97 is the gid for the dovecot user .. which owns just about everything deliver could ever touch.
What am I missing ?
A non-root process is not allowed to change it's privelages.
Brad wrote:
Okay .. have dovecot set up with following settings :
userdb static {
args = uid=97 gid=97 home=/export/dovecot/mail/%d/%umail=mbox:/export/dovecot/mbox/%d/%u/ }
passdb passwd-file { # Path for passwd-file args = /etc/dovecot-passdb }
Passdb works I think in the sense that I can log into dovecot using a regular mail client.
The real issue is when I try to deliver any type of mail using dovecot-lda (deliver).
deliver is setuid and setgid dovecot .. I event se the static mail dirs above to be owned by dovecot (I know .. a no no .. but wanted to trace down issue)
I also have
first_valid_uid = 96
and
first_valid_uid = 96
Now .. when I try to do this ..
echo "A Test Message" | /usr/local/libexec/dovecot/deliver -d existinguser
I get this ..
master in: USER 1 echo service=deliver dovecot: Mar 11 23:45:24 Info: auth(default): master out: USER 1 echo uid=97 gid=97 home=/export/dovecot/mail//echo mail=mbox:/export/dovecot/mbox//echo/ dovecot: Mar 11 23:45:24 Error: auth(default): deliver: Fatal: setgroups(97) failed: Operation not permitted
97 is the gid for the dovecot user .. which owns just about everything deliver could ever touch.
What am I missing ?
Ok, this has come to bite me on the rear end now....
On 3/16/06, Peter Fern dovecot@obfusc8.org wrote:
A non-root process is not allowed to change it's privelages.
<snip> > > > >deliver: Fatal: setgroups(97) failed: Operation not permitted
Why does deliver try to change it's group, it it's setgid to the group it's trying to change to?
I have -rwsr-sr-x 1 dovecotmail dovecotmail 2816973 Jun 9 19:14 /usr/local/libexec/dovecot/deliver dovecotmail being 112. The virtual user is 112, and my error is Jun 9 20:33:46 mafeking deliver(joeblogs): setgroups(112) failed: Operation not permitted
WHY does deliver try to change it's gid, when it does need to!?!?
Is this the issue? Or is there another solution?
Thanks
Tim
Linux Counter user #273956
Is this the issue? Or is there another solution?
Ok, a temporary solution was to comment out a few lines of code in dovecot/src/lib/restrict-access.c
Lines 143-146 (beta8) (the first part of the "if (env == NULL) {" block
/* groups - the getgid() checks are just so we don't fail if we're
not running as root and try to just use our own GID. Do this
before chrooting so initgroups() actually works. */
env = getenv("RESTRICT_SETGID");
gid = env == NULL ? 0 : (gid_t)strtoul(env, NULL, 10);
if (gid != 0 && (gid != getgid() || gid != getegid())) {
if (setgid(gid) != 0)
i_fatal("setgid(%s) failed: %m", dec2str(gid));
env = getenv("RESTRICT_USER");
if (env == NULL) {
/* user not known, use only this one group */
if (setgroups(1, &gid) < 0) {
i_fatal("setgroups(%s) failed: %m",
dec2str(gid));
}
} else {...
I know this isn't desirable, but it works.
Any suggestions Timo as to other methods fixes?
Thanks
Tim
Linux Counter user #273956
Timo, any ideas on this one for the next release? I feel a little scared running it like this, even though it's only the deliver binary that was linked against the changed libraries...
Tim
On 6/9/06, Timothy White dovecot.user@weirdo.bur.st wrote:
Is this the issue? Or is there another solution?
Ok, a temporary solution was to comment out a few lines of code in dovecot/src/lib/restrict-access.c
Lines 143-146 (beta8) (the first part of the "if (env == NULL) {" block
/* groups - the getgid() checks are just so we don't fail if we're not running as root and try to just use our own GID. Do this before chrooting so initgroups() actually works. */ env = getenv("RESTRICT_SETGID"); gid = env == NULL ? 0 : (gid_t)strtoul(env, NULL, 10); if (gid != 0 && (gid != getgid() || gid != getegid())) { if (setgid(gid) != 0) i_fatal("setgid(%s) failed: %m", dec2str(gid)); env = getenv("RESTRICT_USER"); if (env == NULL) { /* user not known, use only this one group */ if (setgroups(1, &gid) < 0) { i_fatal("setgroups(%s) failed: %m", dec2str(gid)); } } else {...
I know this isn't desirable, but it works.
Any suggestions Timo as to other methods fixes?
Thanks
Tim
Linux Counter user #273956
-- Linux Counter user #273956
On Mon, 2006-06-12 at 21:31 +0800, Timothy White wrote:
Timo, any ideas on this one for the next release? I feel a little scared running it like this, even though it's only the deliver binary that was linked against the changed libraries...
Already fixed this in CVS. I just don't set the SETUID/SETGID environments if they match the effective uid/gid.
On 6/12/06, Timo Sirainen tss@iki.fi wrote:
On Mon, 2006-06-12 at 21:31 +0800, Timothy White wrote:
Timo, any ideas on this one for the next release? I feel a little scared running it like this, even though it's only the deliver binary that was linked against the changed libraries...
Already fixed this in CVS. I just don't set the SETUID/SETGID environments if they match the effective uid/gid.
Thanks!
Tim
Linux Counter user #273956
participants (5)
-
Brad
-
Peter Fern
-
Timo Sirainen
-
Timothy White
-
Timothy White