示例procmailrc：
SHELL=/bin/bash
LOGFILE=$HOME/procmail.log
VERBOSE=yes
:0
* ^Subject: envdump please$
{
LOG="`id`"
:0
/dev/null
}/etc/group文件包含（注意其他用户名是徒劳的尝试）：
someuser:x:504:
s3:x:505:someuser,someotheruser,postfix,postdrop,mail,root如果我以“someuser”的身份运行id命令：
[someuser@lixyz-pqr ~]$ id
uid=504(someuser) gid=504(someuser) groups=504(someuser),505(s3)但是，当我通过发送主题为“envdump please”的电子邮件来运行procmail时，505/s3组消失了（这在procmail.log中）：
procmail: [17618] Mon Dec 19 17:39:50 2011
procmail: Match on "^Subject: envdump please$"
procmail: Executing "id"
procmail: Assigning "LOG=uid=504(someuser) gid=504(someuser) groups=504(someuser)"
uid=504(someuser) gid=504(someuser) groups=504(someuser)procmail: Assigning "LASTFOLDER=/dev/null"此服务器运行Fedora 14和Postfix 2.7.5
2条答案
按热度按时间dxxyhpgq1#
Procmail未安装setuid。
对于背景，它应该看起来像：
您可以通过以下方式设置：
yeotifhr2#
我假设您正在使用postfix和procmail。Postfix，由于我无法找到的原因，当它以收件人用户身份运行procmail时，会从收件人用户中剥离补充组。这就是为什么您的procmail LOG示例只显示主ID，即使您的/etc/groups列出了更多的组成员。（Sendmail不这样做;这是一个后缀的东西）。
我的解决方案是通过sudo清洗命令来强制接收用户恢复其正常的组权限。没有用户或主组更改发生，我们所做的只是让补充组恢复到/etc/group所说的状态。只有当您拥有root访问权限或其他一些编辑sudoers的访问权限时，这才有效。
编辑你的/etc/sudoers（或创建一个新的.d文件）并添加：
someuser ALL=(someuser) NOPASSWD: /bin/id其中/bin/id是要在procmail配方中运行的程序，并包含正确的补充组。
然后通过sudo修改你的procmail配方来清洗你的命令：
| /bin/sudo -u someuser /bin/id如果你没有root权限，你可以使用公钥（而不是密码）通过ssh进行类似的清洗。或者你可以创建一个监听命名管道的守护进程（尽管保持守护进程运行可能需要root权限：也就是使用systemd服务文件）。如果可行的话，另一个选择是将/etc/passwd中的主组设置为该procmail调用所需的组。当然，这限制了您仅为该调用使用这种方式修复问题。
更多详情：postfix is calling setgroups()，只使用主组作为补充组列表。它不必这样做，但程序员决定它应该这样做。我找不到关于它为什么这样做的文档。我真的不明白这对安全性有什么帮助。
我研究了使用newgrp或sg来重置补充组，但无论如何我都无法恢复它们，即使源代码显示它应该这样做。使用strace，一旦它们被删除，内核功能系统将禁止重新获得这些组。