我在main.cf设置了default_privs=myuser ，这是一个perl脚本，在这个用户的上下文中执行。
在perl脚本中，我添加了一些debugging来打印出用户：
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 ... ...
该文件被复制。 我的理解是如何做到这一点，如果我之前做了my su myuser ， cp命令运行在与perl脚本相同的用户上下文中。 区别在哪里？
更新：文件共享组“myuser”具有写入权限仅作为补充组添加到此用户。 我将其更改为用户的主要组，现在它工作。 无论如何，这种行为看起来很奇怪。
好的，至less我有两个引用为什么这种行为发生在后缀。 但是我不确定下面的行为背后是什么概念。 一个可能的解释是在这个线程： GID，当前，主要，补充，有效和真实的组ID？ 。 也许你可以对unix的专家有进一步的解释。
你的情况在postfix邮件列表中被这两个问题所证实。 在这里关于内容filter和关于别名的脚本 。 这两个问题是关于由postfix执行的脚本没有执行其次级组，与您的情况类似。 解释是：
当你使用
default_privs来指定执行脚本的用户时，postfix只携带了主用户组，即用户的GID。 当您使用terminal/ SSH调用命令时，所有辅助组已在login时被携带。 所以这就是为什么UNIX无法识别执行perl脚本的用户是否拥有对该文件夹具有写入权限的辅助组。
一种解决scheme（除了replace主要组）是在pipe道服务中指定组名。 因为你提到你覆盖local_transport ，那么你可以使用该pipe local_transport。