On Sun, Feb 25, 2001 at 09:51:29AM +1100, Brian May wrote: > Hello, > > yesterday I changed some of my UID and GID assignments. Including > GID=postdrop, used by postfix. this type of change needs to be done very carefully, you really should not do it while things are running under a uid you are reallocating. weird stuff can happen! > So I did: > > chgrp postdrop /usr/sbin/postdrop /var/spool/postfix/postdrop > > and restarted postfix. Fortunately, I ran a test mail, to ensure that > mail was still working - it wasn't. > > The reason? When I typed in the above command, it disabled the setgid > flag from postdrop. Argghh! > > I turned it back on, and restarted postfix. Only, the same copy > postdrop was still running, so I killed it - this in turned killed the > mail which was in transit, which was silently dropped (at least I > haven't received it yet, and it has been over 12 hours; mailq reports > an empty mail queue). your test mail never entered the mail queue, since you don't have a world writable maildrop (this is not /var/mail) it was impossible for the message to get inserted into the postfix mail queue. > So, for future reference, is it possible to: > > a) change the GID of an executable file without resetting the > S bits? no, this is a security feature of the kernel, it is actually rather common on unix like systems and i think its defined by either posix or SUS but i could be mistaken. s bits are also removed if the file is written to (so a world writable setuid program can't be turned into a world writable setuid /bin/sh by simply doing a cat /bin/sh > /usr/bin/setuid) in the future if you have to change this quickly do something like: chgrp postdrop /usr/bin/postdrop ; chmod g+s /usr/bin/postdrop but note that your maildrop (living under /var/spool/postfix) would need to be chgrped at the same time. a postfix restart generally does this since most everything under there is a socket and the sockets are recreated on postfix restarts. > b) restart postdrop without the risk of loosing any mail that is being > delivered? postdrop is not a daemon, its invoked by /usr/sbin/sendmail when it finds its unable to write to the postfix maildrop. > Fortunately, I only lost the test mail I sent myself (I think!), but I > am surprised that postfix didn't queue the message and try to re-send > it latter (is this a bug?). resend what? the test mail never entered the postfix queue, postfix was never aware that the message existed in the first place. this occured because you had a fatal misconfiguration for a short ammount of time: the maildrop was NOT world writable, AND the postdrop command was NOT setgid. if you sent the message through tcp port 25 it might have got in, depending on what uid postfix was running as, and what uid /var/spool/postfix/maildrop was set to. the simple `mail' command pipes the message into /usr/sbin/sendmail though, and it just pipes it to the postdrop command if it can't write to the maildrop. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgp99UlygsQxx.pgp
Description: PGP signature