my $exec_username = $ENV{LOGNAME} || $ENV{USER} || getpwuid($<);
$logger->info("Script is running in context of user:".$exec_username);
如果脚本是由传入的电子邮件触发的,我可以看到脚本在用户“myuser”的上下文中运行.
稍后在脚本中,我尝试复制文件.我使用反引号来获取STDOUT和STDERR的输出：
my $copycmd = "cp -f -v '".$final_tiff."' '".$fax_file_name."'";
$logger->info("Copy command: ".$copycmd);
my $copylog=`$copycmd 2>&1`;
$logger->info($copylog);
但这给了我：
cp: cannot create regular file ... : Permission denied
用户“myuser”是对glusterfs文件共享具有rw权限的组的一部分.正如您在代码中看到的,我还打印出复制命令.如果我使用相同的命令并在shell中运行它,例如：
su myuser cp ... ...
文件被复制.根据我的理解,如果我之前使用su myuser,那么cp命令是如何在与perl脚本相同的用户上下文中运行的.区别在哪里？
更新：文件共享whare’myuser’具有写权限的组仅作为补充组添加到该用户.我将其更改为用户的主要组,现在它可以工作.无论如何,这种行为对我来说很奇怪.
解决方法
您在postfix邮件列表中的这两个问题确认了您的案例. Here about content-filter和@L_502_3@.这两个问题是关于一个由postfix执行的脚本不带有它的辅助组,与你的情况类似.解释是：
When you use
default_privsto 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.
一种解决方案(替换主要组除外)是在pipe服务中指定组名.因为您提到您覆盖了local_transport,所以您可以将该管道用于local_transport.