Bug 475347

Summary: deliver setgid mail permission removed in latest update
Product: [Fedora] Fedora Reporter: Tom Horsley <horsley1953>
Component: dovecotAssignee: Michal Hlavinka <mhlavink>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: dan, mhlavink
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-26 12:18:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tom Horsley 2008-12-08 22:21:28 UTC
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

Comment 1 Michal Hlavinka 2008-12-09 09:34:39 UTC
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

Comment 2 Tom Horsley 2008-12-09 10:47:37 UTC
>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.

Comment 3 Michal Hlavinka 2008-12-11 07:15:37 UTC
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.

Comment 4 Tom Horsley 2008-12-11 12:35:23 UTC
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.

Comment 5 Michal Hlavinka 2009-01-26 12:18:26 UTC
I think this bug was opened for enough time to be found by people facing this problem.