Red Hat Bugzilla – Bug 475347
deliver setgid mail permission removed in latest update
Last modified: 2009-01-26 07:18:26 EST
Description of problem:
The setgid "mail" permission was set on the /usr/libexec/dovecot/deliver
program until the update I installed last night. Now it shows up as:
[root@zooty ~]# ls -l /usr/libexec/dovecot/deliver
-rwxr-xr-x 1 root root 831840 Dec 2 12:04 /usr/libexec/dovecot/deliver
This is a big problem (resulting in the loss of all my mail till I
noticed this). If you have a ~/.forward file that pipes into deliver,
a non-setgid deliver cannot read the /etc/dovecot.conf file to
dig up the configuration info it needs to run, so it gives a fatal
error which provokes postfix into bouncing the mail into the bit bucket.
Version-Release number of selected component (if applicable):
I installed the update on both my x86_64 and i386 fedora 10 partitions,
and I see deliver is missing the setgid bit in both, so I'd imagine
it is 100% reproducable.
Steps to Reproduce:
1. install update
2. stop getting mail
3. wonder why no mail shows up and look in logs to see the fatal errors
mail stop working
mail keeps working
This did at least lead me to discover the postfix soft_bounce setting
(which I not have turned on :-). I also verified that the previous
deliver had the setgid bit by examining my backup files:
-rwxr-sr-x 1 root mail 798120 Nov 3 06:56 cb-2008-11-29-09-26-58/usr/libexec/dovecot/deliver
-rwxr-sr-x 1 root mail 831808 Nov 3 06:56 cb-2008-12-08-09-20-24/usr/libexec/dovecot/deliver
-rwxr-xr-x 1 root root 831840 Dec 2 12:04 latest/usr/libexec/dovecot/deliver
Hi, this is a long story (see bz#436287). We made deliver setgid and dovecot.conf not world readable because of possible ssl key password exposure. But it wasn't as good idea as it looked at first. We've discussed this with upstream developer and the result is new !include_try directive.
dovecot.conf should be world readable (not world writeable) and deliver should not have this setgid. It's bad we were not able to revert this setgid thing before F-10 was shipped, but we did it as soon as possible. Note that setgid was only in one released version not before and not after.
I'll look what happens if "old" version is installed and than upgraded.
remove setgid bit from deliver
make dovecot.conf readable for other, if you need to hide something just use !include_try dovecot.conf.2 or whatever file, put it there and make this new file readable only by root. BUT: deliver will skip include_try and won't look into the referred file. Only dovecot itself (and *-login) will know about its content. Deliver was never intended by upstream to have a setgid or setuid bits.
Thanks for the report,
>I'll look what happens if "old" version is installed and than upgraded.
Be sure you modify your old dovecot.conf first. I think that was the key.
It left me with my old 640 root mail dovecot.conf file and a new
644 root root dovecot.conf.rpmnew file, but deliver could no longer
read the old dovecot.conf file.
I actually already fixed this by making my old dovecot.conf file 644,
but then noticed the setgid deliver in my backups, so figured that was
what changed. I'll just leave it 644 (there are no keys or anything
embedded in my file anyway).
Thanks for the explanation.
I've tested it (just install / upgrade - no run) and old bad permissions stay.
Can you provide me that error messages you've got because this, please? It'd be helpful to recognize duplicated bugs.
The message only showed up in /var/log/maillog, and is probably unique
to postfix, but here's a sample:
Dec 8 05:40:03 zooty postfix/local: 34CD3A8A5D: to=<email@example.com>, orig_to=<tom@localhost>, relay=local, delay=0.1, delays=0.06/0/0/0.05, dsn=5.3.0, status=bounced (Command died with status 2: "/usr/local/bin/bogoliver". Command output: Fatal: open(/etc/dovecot.conf) failed: Permission denied )
Dec 8 05:40:03 zooty postfix/qmgr: 34CD3A8A5D: removed
The /usr/local/bin/bogoliver program it mentions is really just a simple
program that first runs bogofilter to add the X-Bogosity header for use
in a sieve filter script, then runs deliver. If one of the children
exits abnormally, it passes that exit status on.
I think this bug was opened for enough time to be found by people facing this problem.