☰

后缀参数 default_privs

tag-icon • tag-icon postfix file-permissions perl user-permissions glusterfs
后缀参数 default_privs

我已经设置了default_privs=myuser，main.cf这是一个 perl 脚本，在该用户的上下文中执行。

在 perl 脚本中我添加了一些调试来打印出用户：

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 脚本相同的用户上下文中运行。区别在哪里？

更新：文件共享中“myuser”具有写入权限的组仅作为此用户的补充组添加。我将其更改为用户的主要组，现在它可以正常工作了。无论如何，这种行为对我来说看起来很奇怪。

答案1

好的，至少我有两个参考资料可以解释为什么这种行为发生在 Postfix 中。但我不确定以下行为背后的概念是什么。一个可能的解释是在这个帖子中：GID、当前、主要、补充、有效和真实组 ID？。也许你可以得到专家的进一步解释unix系统。

您的情况已通过 postfix 邮件列表中的这两个问题得到证实。这里有关内容过滤器和这里是关于别名脚本。这两个问题是关于postfix执行的脚本没有携带其次要组，和你的情况类似。解释是：

当您使用default_privs指定执行脚本的用户时，postfix 只会携带用户的主要组，即 GID。当您使用终端/SSH 调用命令时，所有次要组在您登录时都已携带。因此，这就是为什么 UNIX 无法识别执行 perl 脚本的用户具有对该文件夹具有写权限的次要组。

一种解决方案（除了替换主组）是在管道服务。因为您提到您覆盖了local_transport，所以您可以将其pipe用于 local_transport。

相关内容