After updating from Postfix 3.2.4 to 3.3.1-r1, numerous file permissions were incorrect, resulting in MUAs being unable to send mail because postdrop was not functioning correctly. Correct permissions in /usr/sbin: babylon5:root:~:27 # ls -l /usr/sbin/post* -rwxr-xr-x 1 root root 18768 Sep 5 11:20 /usr/sbin/postalias* -rwxr-xr-x 1 root root 14648 Sep 5 11:20 /usr/sbin/postcat* -rwxr-xr-x 1 root root 180376 Sep 5 11:20 /usr/sbin/postconf* -rwx--s--x 1 root postdrop 14760 Sep 5 11:20 /usr/sbin/postdrop* -rwxr-xr-x 1 root root 14520 Sep 5 11:20 /usr/sbin/postfix* -rwxr-xr-x 1 root root 10288 Sep 5 11:20 /usr/sbin/postkick* -rwxr-xr-x 1 root root 10344 Sep 5 11:20 /usr/sbin/postlock* -rwxr-xr-x 1 root root 10480 Sep 5 11:20 /usr/sbin/postlog* -rwxr-xr-x 1 root root 18736 Sep 5 11:20 /usr/sbin/postmap* -rwxr-xr-x 1 root root 27384 Sep 5 11:20 /usr/sbin/postmulti* -rwx--s--x 1 root postdrop 18888 Sep 5 11:20 /usr/sbin/postqueue* -rwxr-xr-x 1 root root 23264 Sep 5 11:20 /usr/sbin/postsuper* Actual: minbar:root:~:1 # ls -l /usr/sbin/post* -rwxr-xr-x 1 root root 18768 Sep 2 10:05 /usr/sbin/postalias* -rwxr-xr-x 1 root root 14648 Sep 2 10:05 /usr/sbin/postcat* -rwxr-xr-x 1 root root 180600 Sep 2 10:05 /usr/sbin/postconf* -rwxr-xr-x 1 root root 14760 Sep 2 10:05 /usr/sbin/postdrop* -rwxr-xr-x 1 root root 14520 Sep 2 10:05 /usr/sbin/postfix* -rwxr-xr-x 1 root root 10288 Sep 2 10:05 /usr/sbin/postkick* -rwxr-xr-x 1 root root 10344 Sep 2 10:05 /usr/sbin/postlock* -rwxr-xr-x 1 root root 10480 Sep 2 10:05 /usr/sbin/postlog* -rwxr-xr-x 1 root root 18736 Sep 2 10:05 /usr/sbin/postmap* -rwxr-xr-x 1 root root 27384 Sep 2 10:05 /usr/sbin/postmulti* -rwxr-xr-x 1 root root 18880 Sep 2 10:05 /usr/sbin/postqueue* -rwxr-xr-x 1 root root 23264 Sep 2 10:05 /usr/sbin/postsuper* The postfix spool directory also contained incorrect permissions. 'postfix set-permissions' would not fix the problems and reported multiple file-not-found errors. Rolling back to 3.2.4 resolved all permissions-related problems.
3.3.1-r1 seems to work fine on my system, although postdrop and postqueue have 2755 instead of 2711. I also installed postfix-3.3.1-r1 on a different system which had never had postfix before and the permissions ended up the same.: ll /usr/sbin/post* -rwxr-xr-x 1 root root 18K Jul 25 16:49 /usr/sbin/postalias -rwxr-xr-x 1 root root 18K Jul 25 16:49 /usr/sbin/postcat -rwxr-xr-x 1 root root 172K Jul 25 16:49 /usr/sbin/postconf -rwxr-sr-x 1 root postdrop 14K Jul 25 16:49 /usr/sbin/postdrop -rwxr-xr-x 1 root root 14K Jul 25 16:49 /usr/sbin/postfix -rwxr-xr-x 1 root root 39K Dec 10 2017 /usr/sbin/postgrey -rwxr-xr-x 1 root root 24K Dec 10 2017 /usr/sbin/postgreyreport -rwxr-xr-x 1 root root 9.9K Jul 25 16:49 /usr/sbin/postkick -rwxr-xr-x 1 root root 9.9K Jul 25 16:49 /usr/sbin/postlock -rwxr-xr-x 1 root root 11K Jul 25 16:49 /usr/sbin/postlog -rwxr-xr-x 1 root root 18K Jul 25 16:49 /usr/sbin/postmap -rwxr-xr-x 1 root root 27K Jul 25 16:49 /usr/sbin/postmulti -rwxr-sr-x 1 root postdrop 22K Jul 25 16:49 /usr/sbin/postqueue -rwxr-xr-x 1 root root 27K Jul 25 16:49 /usr/sbin/postsuper
(In reply to Phil Stracchino (Unix Ronin) from comment #0) > 'postfix > set-permissions' would not fix the problems and reported multiple > file-not-found errors. what's the output of postfix set-permissions? (In reply to gentoo-user from comment #1) > 3.3.1-r1 seems to work fine on my system, although postdrop and postqueue > have 2755 instead of 2711 2755 is the correct permissions for postdrop and postqueue - see lines 128 and 129 in postfix-files
For me: # postfix set-permissions chown: cannot access '/etc/postfix/postfix-files.d': No such file or directory # echo $? 1 Installing 3.3.1 had removed that directory (I didn't have any files of my own there): <<< dir /etc/postfix/postfix-files.d >>> Regenerating /etc/ld.so.cache... >>> Original instance of package unmerged safely. Creating the directory set the executable file permissions but exited with another error: chown: cannot access '/usr/share/man/man1/postalias.1': No such file or directory
(In reply to Chris Mayo from comment #3) > For me: > > # postfix set-permissions > chown: cannot access '/etc/postfix/postfix-files.d': No such file or > directory > # echo $? > 1 > > Installing 3.3.1 had removed that directory (I didn't have any files of my > own there): > > <<< dir /etc/postfix/postfix-files.d > >>> Regenerating /etc/ld.so.cache... > >>> Original instance of package unmerged safely. Thanks for the reply. That is not expected and I'll have a look. > Creating the directory set the executable file permissions but exited with > another error: > > chown: cannot access '/usr/share/man/man1/postalias.1': No such file or > directory That's expected. We have the bzipped versions of man pages (with bz2 extensions)
pushed without a revbump. portage's behaviour regarding installing empty directories changed. hence the postfix-files.d removal and the subsequent failure. Please check if you still have a problem with postfix-3.3.1-r1. Thank you.
Still seeing an error during the install phase. /usr/libexec/postfix/postfix-script: line 74: cd: /usr/lib64/postfix/3.2.4: No such file or directory /usr/libexec/postfix/postfix-script: line 74: cd: /usr/lib64/postfix/3.2.4: No such file or directory >>> mail-mta/postfix-3.3.1-r1 merged. >>> Regenerating /etc/ld.so.cache... This error is coming because postfix-script runs before /etc/postfix/main.cf has been updated with the new Postfix version string. Permissions in /var/spool/postfix/ after install are correct, but permissions in /usr/sbin are not. 'postfix check' warns: narn:root:~:18 # postfix check postfix/postfix-script: warning: not owned by group postdrop: /usr/sbin/postqueue postfix/postfix-script: warning: not owned by group postdrop: /usr/sbin/postdrop postfix/postfix-script: warning: not set-gid or not owner+group+world executable: /usr/sbin/postqueue postfix/postfix-script: warning: not set-gid or not owner+group+world executable: /usr/sbin/postdrop But 'postfix set-permissions' does not fix it even after updating main.cf. I think the problem is that as installed, /usr/share/doc/postfix-3.3.1-r1/html/ and /usr/share/doc/postfix-3.3.1-r1/readme/ do not exist, which causes 'postfix set-permissions' to bail before it has finished setting permissions.
(I *THOUGHT* I successfully refreshed the ebuild ... but maybe I didn't.)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b0f784e9fad46120eafba0c81e605cb9417e2c7f commit b0f784e9fad46120eafba0c81e605cb9417e2c7f Author: Eray Aslan <eras@gentoo.org> AuthorDate: 2018-09-07 13:44:22 +0000 Commit: Eray Aslan <eras@gentoo.org> CommitDate: 2018-09-07 13:45:02 +0000 mail-mta/postfix: remove doc USE flag for now otherwise postfix set permissions cannot find the correct files and bails out Bug: https://bugs.gentoo.org/665280 Package-Manager: Portage-2.3.49, Repoman-2.3.10 mail-mta/postfix/postfix-3.3.1-r1.ebuild | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-)
I have this bug on an all-stable x86 box. It remained even after the doc flag was suppressed. So 2 builds have been bad. It is easy to work around: (as root) cd /usr/sbin chgrp postdrop postdrop postqueue chmod g+s postdrop postqueue However, this should not really be necessary. Obviously the ebuild should set the permnissions correctly on these binaries.
I performed these same steps to correct the permissions and it fixed the issues I had after the latest upgrade as well.
Per https://bugs.gentoo.org/651082#c8: man page compression also needs to be disabled to "set-permissions" to work. (So PORTAGE_COMPRESS="" needs to be done somewhere.)
Also related to bug 651082.
'git send-email' is broken on =postfix-3.3.1-r1 for me as well. postdrop: warning: mail_queue_enter: create file maildrop/855503.15090: Permission denied Rolling back to 3.2.4 fixes permissions. Should I do something one-off manually to recover permissions or ebuilds needs a fix? $ emerge --info postfix mail-mta/postfix-3.2.4::gentoo was built with the following: USE="berkdb eai pam sasl ssl -cdb -doc -dovecot-sasl -hardened -ldap -ldap-bind -libressl -lmdb -mbox -memcached -mysql -nis -postgres -selinux -sqlite" ABI_X86="(64)" CFLAGS="-march=sandybridge -mtune=sandybridge --param=l1-cache-size=32 --param=l1-cache-line-size=64 --param=l2-cache-size=8192 -O2 -pipe -fdiagnostics-show-option -frecord-gcc-switches -Wno-comment" CXXFLAGS="-march=sandybridge -mtune=sandybridge --param=l1-cache-size=32 --param=l1-cache-line-size=64 --param=l2-cache-size=8192 -O2 -pipe -fdiagnostics-show-option -frecord-gcc-switches -Wno-comment"
> $ emerge --info postfix > > mail-mta/postfix-3.2.4::gentoo was built with the following: > USE="berkdb eai pam sasl ssl -cdb -doc -dovecot-sasl -hardened -ldap > -ldap-bind -libressl -lmdb -mbox -memcached -mysql -nis -postgres -selinux > -sqlite" ABI_X86="(64)" > CFLAGS="-march=sandybridge -mtune=sandybridge --param=l1-cache-size=32 > --param=l1-cache-line-size=64 --param=l2-cache-size=8192 -O2 -pipe > -fdiagnostics-show-option -frecord-gcc-switches -Wno-comment" > CXXFLAGS="-march=sandybridge -mtune=sandybridge --param=l1-cache-size=32 > --param=l1-cache-line-size=64 --param=l2-cache-size=8192 -O2 -pipe > -fdiagnostics-show-option -frecord-gcc-switches -Wno-comment" Sorry. The above was working configuration. This one is not working: $ emerge --info postfix mail-mta/postfix-3.3.1-r1::gentoo was built with the following: USE="berkdb eai pam sasl ssl -cdb -dovecot-sasl -hardened -ldap -ldap-bind -libressl -lmdb -mbox -memcached -mysql -nis -postgres -selinux -sqlite" ABI_X86="(64)" CFLAGS="-march=sandybridge -mtune=sandybridge --param=l1-cache-size=32 --param=l1-cache-line-size=64 --param=l2-cache-size=8192 -O2 -pipe -fdiagnostics-show-option -frecord-gcc-switches -Wno-comment" CXXFLAGS="-march=sandybridge -mtune=sandybridge --param=l1-cache-size=32 --param=l1-cache-line-size=64 --param=l2-cache-size=8192 -O2 -pipe -fdiagnostics-show-option -frecord-gcc-switches -Wno-comment"
Created attachment 547122 [details] mail-mta:postfix-3.3.1-r1:20180917-204501.log build log of mail-mta:postfix-3.3.1-r1:20180917-204501.log is it helps.
Created attachment 547124 [details] emerge--info emerge --info output.
(In reply to Sergei Trofimovich from comment #13) > 'git send-email' is broken on =postfix-3.3.1-r1 for me as well. > > postdrop: warning: mail_queue_enter: create file maildrop/855503.15090: > Permission denied > > Rolling back to 3.2.4 fixes permissions. Should I do something one-off > manually to recover permissions or ebuilds needs a fix? Sergei, You can fix it manually for now, if you wish, by setting the correct permissions in /usr/sbin and /var/spool/postfix. These are the correct values of the permissions you need to manually fix: -rwxr-sr-x 1 root postdrop 14760 Sep 8 17:22 /usr/sbin/postdrop* -rwxr-sr-x 1 root postdrop 18880 Sep 8 17:22 /usr/sbin/postqueue* drwx------ 2 postfix root 6 Sep 17 17:31 active/ drwx------ 2 postfix root 6 Sep 8 23:18 bounce/ drwx------ 2 postfix root 6 Nov 25 2010 corrupt/ drwx------ 18 postfix root 134 Oct 12 2014 defer/ drwx------ 18 postfix root 134 Jul 28 2011 deferred/ drwx------ 2 postfix root 6 Sep 15 2012 flush/ drwx------ 2 postfix root 6 Nov 25 2010 hold/ drwx------ 2 postfix root 6 Sep 17 17:31 incoming/ drwx-wx--- 2 postfix postdrop 6 Sep 17 14:46 maildrop/ drwxr-xr-x 2 root root 4096 May 31 2017 pid/ drwx------ 2 postfix root 4096 Sep 7 09:51 private/ drwx--x--- 2 postfix postdrop 68 Sep 7 09:51 public/ drwx------ 2 postfix root 6 Nov 25 2010 saved/ drwx------ 2 postfix root 6 Nov 25 2010 trace/
what's the output if you run postfix set-permissions manually in a broken system?
(In reply to Eray Aslan from comment #18) > what's the output if you run postfix set-permissions manually in a broken > system? # postfix set-permissions postfix: Postfix is running with backwards-compatible default settings postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details postfix: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload" chown: cannot access '/usr/share/doc/postfix-2.8.4/readme': No such file or directory I have that path encoded in: /etc/postfix/main.cf:readme_directory = /usr/share/doc/postfix-2.8.4/readme
(In reply to Sergei Trofimovich from comment #19) > I have that path encoded in: > /etc/postfix/main.cf:readme_directory = /usr/share/doc/postfix-2.8.4/readme After I commented out 'readme_directory' and 'html_directory' emerging new postfix fixed the permissions \o/.
(In reply to Sergei Trofimovich from comment #19) > I have that path encoded in: > /etc/postfix/main.cf:readme_directory = /usr/share/doc/postfix-2.8.4/readme That should only be possible if you zap the config file changes proposed by dispatch-conf or similar. i.e. complaining about a non-existing directory seems to be the correct action here. If wrong configuration is indeed the cause, I dont see how we can fix that
I see that pkg_postinst() runs 'postfix set-permissions' silently: "${EROOT}"/usr/sbin/postfix set-permissions 2>/dev/null Could it not hide it's output and print scary errors when it fails?
(In reply to Eray Aslan from comment #21) > (In reply to Sergei Trofimovich from comment #19) > > I have that path encoded in: > > /etc/postfix/main.cf:readme_directory = /usr/share/doc/postfix-2.8.4/readme > > That should only be possible if you zap the config file changes proposed by > dispatch-conf or similar. i.e. complaining about a non-existing directory > seems to be the correct action here. > > If wrong configuration is indeed the cause, I dont see how we can fix that I just wanted to point out/make explicit that it's normal for this config to contain the wrong (outdated) information when the ebuild is running "postfix set-permissions", as the user has not yet had a chance to run etc-update until after the ebuild has completed. It seems to me that... 1.) "postfix set-permissions" shouldn't be run by the ebuild, it needs to be run by the user after they've run etc-update. 2.) That means that postfix shouldn't be running when the ebuild is being installed, because it will try to run the installed executables before the permissions have been fixed by "postfix set-permissions".
(In reply to Philippe Chaintreuil from comment #23) > I just wanted to point out/make explicit that it's normal for this config to > contain the wrong (outdated) information when the ebuild is running "postfix > set-permissions", as the user has not yet had a chance to run etc-update > until after the ebuild has completed. Yes. That is why we have punted the doc USE flag, i.e. we donot install or set in main.cf the readme/html files by default. > 1.) "postfix set-permissions" shouldn't be run by the ebuild, it needs to be > run by the user after they've run etc-update. I feel that this is not a good solution. A manual step shouldnt be necessary. Think automatic machine image creation, containers etc. - solvable of course but ugly. The ebuild should do the right thing and the system should be usable after "emerge whatever"
Any news on this one? For me without USE=doc this is a blocker for upgrading postfix.
upgrade to postfix-3.3.2. you should be fine. do let us know if you run into any problems. (In reply to Wacław Schiller from comment #25) > For me without USE=doc this is a blocker for upgrading postfix. cant parse this part. USE=doc is gone and wont be coming back.
*** Bug 669304 has been marked as a duplicate of this bug. ***
closing
