procmail 忽略 /etc/group？
示例 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)
但是，当我通过发送电子邮件运行 procmail 时主题为“envdump please”时，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"
此服务器运行的是带有 Postfix 2.7.5 的 Fedora 14
sample procmailrc:
SHELL=/bin/bash
LOGFILE=$HOME/procmail.log
VERBOSE=yes
:0
* ^Subject: envdump please$
{
LOG="`id`"
:0
/dev/null
}
/etc/group file contains (note the other usernames are vain attempts to make this work):
someuser:x:504:
s3:x:505:someuser,someotheruser,postfix,postdrop,mail,root
If I run as "someuser" the command id:
[someuser@lixyz-pqr ~]$ id
uid=504(someuser) gid=504(someuser) groups=504(someuser),505(s3)
However when I run procmail by sending an email with the subject "envdump please", the 505/s3 group disappears (this is in 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"
this server is running Fedora 14 with Postfix 2.7.5
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
procmail 没有安装 setuid。
对于背景，它应该看起来像：
您可以通过以下方式设置：
Procmail wasn't installed setuid.
for background, it should look like:
which you can set up via:
我假设您正在将 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 配方具有正确的补充组。
然后更改您的 procmail 配方以通过 sudo 清洗您的命令：
| /bin/sudo -u someuser /bin/id如果您没有 root 访问权限，您可以使用公钥（而不是密码）通过 ssh 进行类似的清洗。或者您可以创建一个监听命名管道的守护进程（尽管保持守护进程运行可能需要 root：即使用 systemd 服务文件）。如果可行的话，另一种选择是将 /etc/passwd 中的主要组设置为此 procmail 调用所需的组。但当然，这限制了您仅在这一次通话中以这种方式修复问题。
更多详细信息：postfix 正在调用 setgroups() 在调用 procmail 之前，仅将主要组作为补充组列表。它不必这样做，但程序员决定应该这样做。我找不到关于它为什么这样做的文档。我真的无法理解这对安全有何帮助。
我研究了使用 newgrp 或 sg 来重置补充组，但无论如何我都无法恢复它们，即使源代码使它看起来应该如此。使用 strace 会发现，一旦这些组被删除，内核功能系统就会禁止重新恢复它们。
I assume you are using postfix with procmail. Postfix, for reasons I cannot find, strips the supplementary groups from the recipient user when it runs procmail as that user. That is why your procmail LOG example only shows the primary id, even though your /etc/groups lists more group membership. (Sendmail does not do this; it's a postfix thing.)
My solution is to force the recipient user to get its normal group permissions back by washing the command through sudo. No user or primary group change takes place, all we are doing is getting the supplementary groups to revert to what /etc/group says they should be. This only works if you have root access or some other access to edit sudoers.
Edit your /etc/sudoers (or make a new .d file) and add:
someuser ALL=(someuser) NOPASSWD: /bin/idwhere /bin/id is the program you want to run in your procmail recipe with the correct supplementary groups.
Then change your procmail recipe to wash your command through sudo:
| /bin/sudo -u someuser /bin/idIf you do not have root access, you could effect a similar wash through ssh with public keys (not passwords). Or you could create a daemon that listens on a named pipe (though keeping the daemon running may require root: i.e. with a systemd service file). Another option, if feasible, is to set your primary group in /etc/passwd to the one you need for this procmail call. But of course that limits you to fixing things in this manner for just this one call.
Further details: postfix is calling setgroups() before calling procmail, with just the primary group as the supplemental group list. It doesn't have to do this, but the programmers decided it should. I cannot find documentation as to why it does this. I cannot really understand how this would help security in any way.
I investigated using newgrp or sg to reset the supplemental groups, but no matter what I could not get it to restore them, even though the source code makes it appear it should. Using strace it would appear the kernel capabilities system prohibits regaining those groups once they are dropped.