FS#35627 - [postfix] postqueue and postdrop binaries not setgid postdrop in 2.10.0-6

Attached to Project: Arch Linux
Opened by Simon Perry (pezz) - Tuesday, 04 June 2013, 01:16 GMT
Last edited by Gaetan Bisson (vesath) - Monday, 02 March 2015, 17:13 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

After updating to 2.10.0-6 the postqueue and postdrop binaries are not setgid to the postdrop group.

2.10.0-5:
-rwxr-sr-x 1 root postdrop 250928 May 11 05:08 /usr/sbin/postqueue
-rwxr-sr-x 1 root postdrop 197376 May 11 05:08 /usr/sbin/postdrop

2.10.0-6:
-rwxr-xr-x 1 root root 250928 May 31 00:20 /usr/bin/postqueue
-rwxr-xr-x 1 root root 197376 May 31 00:20 /usr/bin/postdrop

This affects access to maildrop and public dirs under /var/spool/postfix (although delivery is still fine if, like my setup, mail is handed off to something like procmail -- so I'm not sure how problematic this is for other delivery types).

Additional info:
* package version(s): 2.10.0-6

* config and/or log files etc.

Warnings from journalctl:

Jun 04 10:38:15 arch postfix/postfix-script[503]: warning: not owned by group postdrop: /usr/sbin/postqueue
Jun 04 10:38:15 arch postfix/postfix-script[504]: warning: not owned by group postdrop: /usr/sbin/postdrop
Jun 04 10:38:15 arch postfix/postfix-script[506]: warning: not set-gid or not owner+group+world executable: /usr/sbin/postqueue
Jun 04 10:38:15 arch postfix/postfix-script[507]: warning: not set-gid or not owner+group+world executable: /usr/sbin/postdrop

Steps to reproduce:

Upgrade to 2.10.0-6
This task depends upon

Closed by  Gaetan Bisson (vesath)
Monday, 02 March 2015, 17:13 GMT
Reason for closing:  Works for me
Comment by Allan McRae (Allan) - Tuesday, 04 June 2013, 01:34 GMT
Re-install the package. This is a failure in the /usr/bin move.
Comment by Simon Perry (pezz) - Tuesday, 04 June 2013, 02:40 GMT
Thanks Allan, re-installing (after the upgrade) sets the correct ownership and permissions.
Comment by Gaetan Bisson (vesath) - Tuesday, 04 June 2013, 13:49 GMT
Is the issue that bash moved just prior to running the install scriptlet? If yes, then there is nothing we can do about it packaging-wise; if no, then I have no idea what can be causing this.
Comment by Allan McRae (Allan) - Tuesday, 04 June 2013, 14:04 GMT
My guess is something in the script run in postfix post_upgrade has a full path in it. But I have not investigated...
Comment by Gaetan Bisson (vesath) - Tuesday, 04 June 2013, 14:48 GMT
Not that I can see: all absolute paths but /bin/sh are extracted from main.cf. I'll just be lazy and not do anything unless other people complain about this.
Comment by Evangelos Foutras (foutrelis) - Tuesday, 04 June 2013, 15:02 GMT
From a quick look it appears that the following is set in /usr/lib/postfix/main.cf:

command_directory = /usr/sbin

You should be able to override it in post_install, much like it's done for daemon_directory.

There's also a newer bug report ( FS#35640 ) which points out the following upgrade errors:

/usr/lib/postfix/post-install: line 413: /usr/sbin/postconf: No such file or directory
/usr/lib/postfix/post-install: line 420: /usr/sbin/postconf: No such file or directory
Comment by Gaetan Bisson (vesath) - Tuesday, 04 June 2013, 16:08 GMT
foutrelis: Right! That's of course because people cannot merge their main.cf instantly as the package gets upgraded - that escaped me. :)

I'll push an updated postfix to [extra] soon.
Comment by Gaetan Bisson (vesath) - Tuesday, 04 June 2013, 16:24 GMT
postfix-2.10.0-7 should prevent this from happening from now on.
Comment by georg (fordprefect) - Monday, 02 March 2015, 15:19 GMT
  • Field changed: Percent Complete (100% → 0%)
permissions are still not set post-upgrade, i always need to manually chmod +s these files.
i know this is supposed to be done in /usr/lib/postfix/postinstall but it doesnt (and i cant find no reason).
Comment by Gaetan Bisson (vesath) - Monday, 02 March 2015, 17:13 GMT
Please create a new bug report for your specific issue, and describe it at length.

Loading...