Using mutt commnd with strace -f fails

Question

I'm using the mutt command in linux and it works when running it regularly.

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

When using "strace" it works as well:

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

But when using "strace -f", it fails. Why?

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

The 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

Why does the fork (-f option) ruin it? Thanks!

EDIT: When running the command:

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

The output is:

2333274  216 -rwxr-sr-x   1 root     postdrop   218632 Oct 30  2018 /usr/sbin/postdrop
9426253    4 -rw-r--r--   1 root     root         1629 Oct 30  2018 /usr/share/man/man1/postdrop.1.gz

Answer 1

Your strace log shows that the operation that's actually failing is an attempt to create a file named maildrop/816765.24140 (in a directory somewhere in /var/spool, probably). This, or a similar operation, fails when mutt is run under strace -f and succeeds when mutt is run under strace without the -f option. We can deduce from these facts that it's not mutt itself that's failing, but some subprocess created by mutt. Moreover, the failure code is EACCES, which means the problem is that something doesn't have the access privileges it needs if and only if it's being debugged (strace uses the debugger API to trace execution).

OK, so when does running a process with a debugger attached, cause it to lose access privileges that it otherwise would have? When the process is executing a setuid or setgid program. These are specially marked programs that, normally, run with the access privileges of the user and/or group identity of the owner of the executable file. That gives them the ability to do things that the invoking user can't normally do. The canonical example of such a program is the su utility, which lets you run a shell as some other user if you know that user's password.

When a setuid or setgid program is run with a debugger attached, though, the kernel doesn't grant it its usual access privileges, because that would break security. Imagine that you could run su, with all of its normal superpowers, under gdb -- that would let you bypass the password check and run a shell as any user whenever you want.

Going by the error messages, the program in question is named postdrop, so you can locate the executable and determine if it has one of these special marks with this command:

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

EDIT: (Part of) the reported output of this command on your system is

2333274  216 -rwxr-sr-x   1 root     postdrop   218632 Oct 30  2018 /usr/sbin/postdrop

The numbers and the date aren't important for this question, so let's just look at the four key columns:

   -rwxr-sr-x  root  postdrop  /usr/sbin/postdrop

First, /usr/sbin/postdrop is a plausible full pathname for a program named postdrop that's invoked internally by mutt, so we know we're looking at the right thing. (The other line of reported output from the find command refers to a file /usr/share/man/man1/postdrop.1.gz. Everything in /usr/share/man is (supposed to be) documentation, not programs, so we can ignore that line.)

Second, -rwxr-sr-x gives the access control "mode" of the program -- who is allowed to read, write, and/or execute it. The lowercase "s" is key. In that position, it means that this program is setgid: it will run with the access control group identity of the group that owns the file, not the group identity of the user who ran the program. This is exactly what I speculated was the case. (An ordinary program would have the access control mode -rwxr-xr-x, and a setuid program like sudo would have mode -rwsr-xr-x.)

Third, "root postdrop" tells us the user and group who own the file, in that order. This program executes with access control group identity "postdrop". This is the same name as the program itself, which probably means this group is dedicated to the purpose of giving this program the privileges it needs to do its job (i.e. queue email for transmission).

So, conclusion: You can't use strace -f to observe the entire process of queuing email for transmission because that would involve running a setgid program under the debugger, contrary to system security policy.

This particular aspect of the Unix security policy is hardcoded into the kernel, and makes a lot more sense in the context of 1970s timesharing systems. If you could run arbitrary code with the postdrop group's access privileges (which the debugger API would let you do, if debugging a setgid program didn't cancel the setgid effect) then you could probably read email that was in the process of being sent by other users on the same system. Nobody wants that.

If you're on a personal workstation, one that only you can use anyway, then you should be able to bypass this rule by running strace -f mutt as root instead of your normal user account. Root can already read everyone's mail, so the policy is not enforced for them.