postfix/postdrop[17400]: warning: mail_queue_enter: create file maildrop/729504.17400: Permission denied

How does postdrop / maildrop get triggered btw? We don't configure it in master.cf.

EDIT: This was from me recalling removing maildrop in master.cf a while back, but looking that PR up I point out they're not the same thing 😅

They're explained in Postfix docs for anyone curious:

• https://www.postfix.org/MAILDROP_README.html
• https://www.postfix.org/QSHAPE_README.html#maildrop_queue (postdrop explained there, it requires SGID for maildrop/?)

For reference postfix installed on Alpine has maildrop/ permissions of 0730 🤷‍♂️

Perhaps see if it works with 1730, like it is by default in Debian, otherwise if really does need 3730 ok then 👍

I found this mailing list discussion from 8 years ago which directs us to post-install and postfix-files. It's a bit hard for me to follow how it gets 2710 from there instead of 0710 though. There's three commands that are set 2755 though, one of them is postdrop ($command_directory maps to /usr/sbin/ I think?).

postfix check doesn't raise any issues about the lack of special permissions.

A long time ago there was a Postfix release announcement (2002) that mentioned chmod 1733 /var/spool/postfix/maildrop which is pretty close.

No /var/mail-state volume, using chgrp isn't stripping the permission bits?:

$ chgrp amavis /var/spool/postfix/{maildrop,public}
$ stat -c '%a %A %n' /var/spool/postfix/{maildrop,public}
1730 drwx-wx--T /var/spool/postfix/maildrop
2710 drwx--s--- /var/spool/postfix/public

$ ls -l /var/spool/postfix/ | grep -E 'maildrop|public'
drwx-wx--T 1 postfix amavis    6 Mar  5 03:03 maildrop
drwx--s--- 1 postfix amavis  110 Mar  5 03:28 public

I looked into why, and it turns out that this is due to a syscall, so is dependent upon the kernel rather than anything we control within the container 🤔

• https://unix.stackexchange.com/questions/313409/howto-prevent-chgrp-from-clearing-setuid-bit/313425#313425
• https://unix.stackexchange.com/questions/53665/chown-removes-setuid-bit-bug-or-feature/53675#53675

I'm having trouble finding a source on the proposed 3730 + 2730 changes. It seems we should just match what we're getting with Debian unless there is reason that doesn't work?

I did find plenty of users reporting 1730 working for them with the same error, more than those using 3730.

Fix seems to be working on my setup ❤️ - I will monitor it though :)

Turns out this issue was caused by allowPrivilegeEscalation: false in my setup, which caused the postdrop binary to run as another user.. Follow-up is #3619