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): dovecot-1.1.7-1.fc10.x86_64 How reproducible: 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 Actual results: mail stop working Expected results: mail keeps working Additional info: 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. You should: 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, Michal
>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[30304]: 34CD3A8A5D: to=<tom.lan>, 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[2715]: 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.