Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 673484 - =mail-mta/postfix-3.3.1-r1 - [postfix/postdrop] warning: mail_queue_enter: create file maildrop/280988.21576: Permission denied
Summary: =mail-mta/postfix-3.3.1-r1 - [postfix/postdrop] warning: mail_queue_enter: cr...
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Net-Mail Packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-20 13:43 UTC by hs
Modified: 2019-01-04 10:09 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hs 2018-12-20 13:43:21 UTC
Warnings started to appear in my postfix log:

...
[postfix/postdrop] warning: mail_queue_enter: create file maildrop/280988.21576: Permission denied
...

Then I figured, that all my permissions on /var/spool/postfix/maildrop directory are correct, but the ownership and permissions to /usr/sbin/{postqueue,postdrop} are incorrect.

# 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

 See: https://bbs.archlinux.org/viewtopic.php?id=164583

I tried to recompile postfix, but the permissions stayed the same. 

Even though it is easy to fix, I think the ebuild should do this automatically.
Comment 1 Eray Aslan gentoo-dev 2018-12-21 05:32:50 UTC
(In reply to hs from comment #0)
> Even though it is easy to fix, I think the ebuild should do this
> automatically.

It does.  Please post the logs where you recompiled postfix but permissions stayed the same and I'll have a look.

You can also run postfix set-permissions to fix the permissions manually.
Comment 2 hs 2018-12-21 13:43:03 UTC
My bad. I emerged it on new clean system and it did set the permissions correctly. 

Even when I set the permissions and owner incorrectly and emerged it again, ebuild corrected it. 

I checked the ebuild and it runs postfix set-permissions:

# check and fix file permissions
"${EROOT}"/usr/sbin/postfix set-permissions

It even creates Groups and User

pkg_setup() {
    # Add postfix, postdrop user/group (bug #77565)
    enewgroup postfix 207
    enewgroup postdrop 208
    enewuser postfix 207 -1 /var/spool/postfix postfix,mail
}

Well sorry for not checking twice, but I still don't know why it did not set the permissions last time..
I am changing status of this thread to RESOLVED INVALID.

And merry Christmas I guess.
Comment 3 hs 2019-01-02 15:52:34 UTC
Actually now I figured it out.
When I run postfix set-permissions it crashes due to non-existing files:

# postfix set-permissions
chown: cannot access '/usr/share/doc/postfix-2.4.6-r2/readme': No such file or directory

The postfix-2.4.6-r2 is not installed though. I can't seem to find a way to resolve this. On my second machine the set-permissions works just fine with the same version of postfix. Don't know if it has a connection, but the postfix-files text file in /etc/postfix is identical on the other machine.

So when emerging postfix, the postfix set-permissions command fails leaving the binary files with wrong permissions.
Comment 4 hs 2019-01-04 10:09:45 UTC
It checks /etc/postfix/main.cf for directory paths. Since I have upgraded postfix since 2.4 version, I left some old variables, which were not valid anymore.

...
readme_directory = /usr/share/doc/postfix-2.4.6-r2/readme
html_directory = /usr/share/doc/postfix-2.4.6-r2/html
...

So when postfix set-permissions has been executed it read these variables and tried to set permissions, but as they no longer exist, it crashed.

Tried to rebuild postfix, everything works.