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.
Best Answer
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:
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 thatpipe
for local_transport.