postfix parameter default_privs

Question

I have set default_privs=myuser in main.cf, which is a perl script, executed in the context of this user.

In the perl script I added some debug to print out the user:

my $exec_username = $ENV{LOGNAME} || $ENV{USER} || getpwuid($<);
$logger->info("Script is running in context of user:".$exec_username);

If the script is triggered by an incoming email, I can see that the script is running in context of user "myuser".

Later in the script, I try to copy a file. I use backticks to get the output from STDOUT and STDERR:

my $copycmd = "cp -f -v '".$final_tiff."' '".$fax_file_name."'";
$logger->info("Copy command: ".$copycmd);
my $copylog=`$copycmd 2>&1`;
$logger->info($copylog);

But this gives me:

cp: cannot create regular file ... : Permission denied

The user "myuser" is part of a group which has rw permissions on the glusterfs file share. As you can see in the code, I also print out the copy command. If I take the same command and run it in a shell, like:

su myuser
cp ... ...

the file is copied. How can that be, for my understanding, if I do su myuser before, the cp command is running in the same user context than the perl script. Where is the difference?

UPDATE: The group of the fileshare whare the 'myuser' has write permissions was only added as supplementary group to this user. I changed this to the primary group of the user, and now it works. Anyway, this behavior looks very strange to me.

What method do you use for piping email to script? aliases method? transport method? — masegaloeh, Jan 26 '15 at 23:08
**has rw permissions on the *file share*** --> did you mean file share like NFS? — masegaloeh, Jan 27 '15 at 13:38
can you invoke the script manually? e.g. with manually specify stdin and the needed parameter — masegaloeh, Jan 27 '15 at 22:29
yes I can. If I start the script manually from a shell of the user, everything works. Maybe postfix is taking another group and this is the problem. — markus, Jan 28 '15 at 08:25

score 4 · Accepted Answer · edited Apr 13 '17 at 12:37

OK, at least I have two references why this behavior happened in postfix. But I'm not sure what's concept behind below behaviour. One possible explanation was in this thread: GID, current, primary, supplementary, effective and real group IDs?. Maybe you can get the further explanation for the experts in unix.SE.

Your case was confirmed by these two questions in postfix mailing-list. Here about content-filter and here about script from aliases. These two question was about a script that executed by postfix doesn't carry its secondary group, similar with your case. The explanation is:

When you use default_privs to specify the user that execute the script, postfix just carried the primary group i.e. GID of the user. When you invoke command with terminal/SSH, the all secondary group(s) was already carried when you are logged-in. So that's why UNIX doesn't recognize that user who execute perl script has secondary group who has write permission to that folder.

One solution (except replace the primary group) is specifying the groupname in pipe service. Because you mention that you override the local_transport, then you can use that pipe for local_transport.

postfix parameter default_privs

1 Answers1