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.
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. That gives them the ability to do things that the invoking user can't normally do. 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. 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.
WARNING MAIL QUEUE ENTER CREATE FILE MAILDROP CODE
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). We can deduce from these facts that it's not mutt itself that's failing, but some subprocess created by mutt. 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. 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). When running the command: sh -c 'find / -name \*postdrop\* -ls 2> /dev/null' nanosleep(, ^Cstrace: Process 24137 detached
I'm using the mutt command in linux and it works when running it regularly.
0 kommentar(er)
