A Permission Problem

Today I noticed an error in my mail.log file about maildrop, a postfix tool, having permission problems.

The errors look like this:

Aug 22 20:58:01 snapwebsites postfix/postdrop[18189]: warning: mail_queue_enter: create file maildrop/255899.18189: Permission denied
Aug 22 20:58:01 snapwebsites postfix/postdrop[12347]: warning: mail_queue_enter: create file maildrop/524431.12347: Permission denied
Aug 22 20:58:11 snapwebsites postfix/postdrop[18189]: warning: mail_queue_enter: create file maildrop/258810.18189: Permission denied
Aug 22 20:58:11 snapwebsites postfix/postdrop[12347]: warning: mail_queue_enter: create file maildrop/525569.12347: Permission denied
Aug 22 20:58:21 snapwebsites postfix/postdrop[18189]: warning: mail_queue_enter: create file maildrop/259004.18189: Permission denied

As we can see, it's always the same, the main differences are the numbers (process number, email filename numbers.)

So these are all the same errors.

Verifying Your Directory Permissions

Looking around, I could find one main error that people have been having: the folder and binaries with the wrong permissions.

First let's see my folders:

$ ls -l /var/spool/postfix/
drwx-wx--T  2 postfix postdrop 4096 Aug 21 21:10 maildrop
drwx-ws---  2 postfix postdrop 4096 Aug 22 19:19 public

Here I show just the two important directories, the ls command should show you a page worth of sub-directories.

These two directories, as we can see, are expected to have a group set to postdrop. So that is not the problem on my system.

Further, you are expected to have the drwx-wx--T and drwx-ws--- for the permissions. These are important so tools such as maildrop can place files in these folders (w for groups) however, they may not be able to read their own file or others easily. If you have those too, then that's not your problem.

To fix the group, use the chgrp command:

chgrp postdrop /var/spool/postfix/maildrop
chgrp postdrop /var/spool/postfix/public

Changing the group will remove the 's' flag because it's not safe in these circumstances.

chmod g+s /var/spool/postfix/maildrop
chmod g+s /var/spool/postfix/public

To get it 100% right, you may need other flags, not just the group 's' flag.

If you'd rather use a number, we have the masks as shown above:

chmod 3730 /var/spool/postfix/maildrop
chmod 2730 /var/spool/postfix/public

Please make sure your changes were correct by running the ls -l command again and making sure it looks like what I have above.

Verifying the Binaries

Apparently the process uses a couple of binaries. In my case, I can see that the postdrop process is stuck.The stack shows that it is.

$ ls -l /usr/sbin/post*
-r-xr-sr-x 1 root postdrop  14328 Jan 18  2018 /usr/sbin/postdrop
-r-xr-sr-x 1 root postdrop  18376 Jan 18  2018 /usr/sbin/postqueue

This allows any user to send an email and have it saved in the postfix spool.

These two processes are expected to have the group set to postdrop and the permission include 's' for the group.

Again, in my case that was already correct. Nothing to do here. But then what?

Just like above you could use the chgrp command to change the group of those two files:

sudo chgrp postdrop /usr/bin/postdrop
sudo chgrp postdrop /usr/bin/postqueue

And like above, you will have to fix the 's' flag:

sudo chmod g+s /usr/bin/postdrop
sudo chmod g+s /usr/bin/postqueue

And again you can do it with the octal number as follow:

sudo chmod 2555 /usr/bin/postdrop
sudo chmod 2555 /usr/bin/postqueue

Make sure to use ls -l like above to verify that your final changes gave the file the correct permissions.

Now What?

For me, that did not fix anything. That is, all of those permissions were already what they were expected to be. So? What else could I do to fix that problem?

One thing I noticed is that the error shows a path of:

maildrop/123.456

So I was wondering whether it was trying to create the folder in the current directory which could be / or some other invalid directory. Just in case, I looked at the queue directory and it is correct:

$ postconf queue_directory
queue_directory = /var/spool/postfix

That was not the problem.

Systemd and NoNewPrivileges

In my environment, the postdrop tool is being run from my daemon. That service runs as snapwebsites:snapwebsites and it had the NoNewPrivileges set to true. There is the pertinent part of the snapwatchdog.service file:

...
NoNewPrivileges=true
User=snapwebsites
Group=snapwebsites
...

When it comes to run postdrop, that tool is expected to have the right to write to a directory which allows writing by using a specific group. However, having the that NoNewPrivileges parameter set to true prevents the change of group, even though the binary has the proper g+s (gid bit set).

There are two solutions.

Add your service to the group with the following:

...
SupplementaryGroups=postdrop
...

However, that means your service now has permission to write in that same directory as postdrop and that's probably not something you want.

The other solution is to keep the NoNewPrivileges parameter to false (which is the default, but you can also make it explicit):

...
NoNewPrivileges=false
...

Also in my case there is another tool being run by my snapwatchdog and that other tool needs to become root as it wants to add/remove files to the /var/mail/root file.

So in effect, the second solution is really the only one viable in my situation.

What we would need, though, is a way to tell systemd which tool we want to allow getting new privileges. That way the default could be NoNewPrivileges=true, but then you could add a few exception. In our case that would be the postdrop and our sendmail tools.