微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

后缀参数default_privs

我在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-filterhere 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.

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐