将 mutt commnd 与 strace -f 一起使用失败

Question

我在 linux 中使用mutt命令，它在定期运行时有效。

mutt myOwnMail@server.com -s "some_subject" -a file.log < file.log #WORKS

使用“strace”时，它也可以：

strace mutt myOwnMail@server.com -s "some_subject" -a file.log < file.log # WORKS

但是当使用“strace -f”时，它会失败。 为什么？

strace -f mutt myOwnMail@server.com -s "some_subject" -a file.log < file.log # FAILS MISERABLY

output：

[pid 24140] open("maildrop/816765.24140", O_RDWR|O_CREAT|O_EXCL, 0644) = -1 EACCES (Permission denied)
[pid 24140] write(2, "postdrop: warning: mail_queue_en"..., 90postdrop: warning: mail_queue_enter: create file maildrop/816765.24140: Permission denied
) = 90
[pid 24140] sendto(3, "<20>Aug 22 20:49:03 postfix/post"..., 124, MSG_NOSIGNAL, NULL, 0) = 124
[pid 24140] rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD TSTP], 8) = 0
[pid 24140] nanosleep({10, 0}, 0x7ffd7e940140) = 0
[pid 24140] open("maildrop/817709.24140", O_RDWR|O_CREAT|O_EXCL, 0644) = -1 EACCES (Permission denied)
[pid 24140] write(2, "postdrop: warning: mail_queue_en"..., 90postdrop: warning: mail_queue_enter: create file maildrop/817709.24140: Permission denied
) = 90
[pid 24140] sendto(3, "<20>Aug 22 20:49:13 postfix/post"..., 124, MSG_NOSIGNAL, NULL, 0) = 124
[pid 24140] rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD TSTP], 8) = 0
[pid 24140] nanosleep({10, 0}, 0x7ffd7e940140) = 0
[pid 24140] open("maildrop/818761.24140", O_RDWR|O_CREAT|O_EXCL, 0644) = -1 EACCES (Permission denied)
[pid 24140] write(2, "postdrop: warning: mail_queue_en"..., 90postdrop: warning: mail_queue_enter: create file maildrop/818761.24140: Permission denied
) = 90
[pid 24140] sendto(3, "<20>Aug 22 20:49:23 postfix/post"..., 124, MSG_NOSIGNAL, NULL, 0) = 124
[pid 24140] rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD TSTP], 8) = 0
[pid 24140] nanosleep({10, 0}, ^Cstrace: Process 24137 detached

为什么叉子（-f 选项）会毁了它？ 谢谢！

Answer 1

您的strace日志显示实际失败的操作是尝试创建一个名为maildrop/816765.24140的文件（可能在/var/spool的某个目录中）。 当mutt在strace -f下运行时，此操作或类似操作会失败，而当mutt在没有-f选项的strace下运行时会成功。 我们可以从这些事实中推断出失败的不是mutt本身，而是mutt创建的某个子进程。 此外，失败代码是EACCES ，这意味着问题是当且仅当它被调试时，某些东西没有它需要的访问权限（ strace使用调试器 API 来跟踪执行）。

好的，那么当运行带有调试器的进程时，会导致它失去原本应该拥有的访问权限吗？ 当进程正在执行setuid或setgid程序时。 这些是特别标记的程序，通常以可执行文件所有者的用户和/或组身份的访问权限运行。 这使他们能够做调用用户通常不能做的事情。 这种程序的典型示例是su实用程序，如果您知道该用户的密码，它可以让您以其他用户的身份运行 shell。

但是，当 setuid 或 setgid 程序在附加调试器的情况下运行时，kernel 不会授予其通常的访问权限，因为这会破坏安全性。 想象一下，您可以在gdb下运行su及其所有正常的超能力——这将让您绕过密码检查并在任何时候以任何用户身份运行 shell。 我认为这就是你的情况。

根据错误消息，有问题的程序名为postdrop ，因此您可以通过运行以下命令来确认这个假设（完全如图所示）：

find / -name '*postdrop*' -ls 2> /dev/null

请将此命令的完整且未经编辑的 output 编辑到您的问题中。