From: Aleatha Parker-W. <al...@so...> - 2012-07-19 22:32:02
|
I'm working with a modified version of strace to collect some information on the long term behaviors of process trees and file system accesses. I've got it logging data on a couple of different systems, some of which I do not have root access to. Each of the users of the system spawns an strace process which then traces all of their shell activity. However, since this is a long term tracing project, users will need to run setuid or setgid executables from time to time. Rather than dropping those bits silently (since strace is running as non-root), and breaking functionality, I'd like to detect that the child process is doing setuid, and detach from it, logging a message that there was an untraced child process. Can you point me at the area of the code where the setuid bits on child processes are handled? I'm assuming it's somewhere around startup_child(), but I'm not spotting it. --apw |
From: Dmitry V. L. <ld...@al...> - 2012-07-19 23:31:42
|
On Thu, Jul 19, 2012 at 03:31:51PM -0700, Aleatha Parker-Wood wrote: > I'm working with a modified version of strace to collect some information on > the long term behaviors of process trees and file system accesses. I've got > it logging data on a couple of different systems, some of which I do not > have root access to. Each of the users of the system spawns an strace > process which then traces all of their shell activity. > > However, since this is a long term tracing project, users will need to run > setuid or setgid executables from time to time. Rather than dropping those > bits silently (since strace is running as non-root), and breaking > functionality, I'd like to detect that the child process is doing setuid, > and detach from it, logging a message that there was an untraced child > process. > > Can you point me at the area of the code where the setuid bits on child > processes are handled? I'm assuming it's somewhere around startup_child(), > but I'm not spotting it. set[ug]id bits of executables are processed solely by kernel during execve(2), strace has no need to handle them: when a traced non-CAP_SETUID process calls execve(2) to execute a privileged executable, linux kernel silently resets euid to uid (and egid to gid). Of course you can modify your version of strace further to probe files passed to execve(2) and handle these bits, but that approach is inevitably racy and therefore is not reliable. -- ldv |