后缀参数default_privs

发布时间：2020-12-15 21:39:26 所属栏目：大数据来源：网络整理

导读：我在main.cf中设置了default_privs = myuser,这是一个perl脚本,在该用户的上下文中执行. 在perl脚本中,我添加了一些调试来打印出用户： my $exec_username = $ENV{LOGNAME} || $ENV{USER} || getpwuid($);$logger-info("Script is running in context of use

我在main.cf中设置了default_privs = myuser,这是一个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脚本相同的用户上下文中运行的.区别在哪里？

更新：文件共享whare’myuser’具有写权限的组仅作为补充组添加到该用户.我将其更改为用户的主要组,现在它可以工作.无论如何,这种行为对我来说很奇怪.

解决方法

好的,至少我有两个引用为什么在postfix中发生这种行为.但我不确定以下行为背后的概念是什么.一个可能的解释是在这个主题： GID,current,primary,supplementary,effective and real group IDs?.也许你可以在 unix.SE获得专家的进一步解释.

您在postfix邮件列表中的这两个问题确认了您的案例. Here about content-filter和here about script from aliases.这两个问题是关于一个由postfix执行的脚本不带有它的辅助组,与你的情况类似.解释是：

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.

一种解决方案(替换主要组除外)是在pipe服务中指定组名.因为您提到您覆盖了local_transport,所以您可以将该管道用于local_transport.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!