How can I get dtrace to run the traced command wit

2019-01-30 08:05发布

站内文章 / 前端开发

51 0

我欲成王，谁敢阻挡

女 | 书童

私信

可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

OS X lacks linux's strace, but it has dtrace which is supposed to be so much better.

However, I miss the ability to do simple tracing on individual commands. For example, on linux I can write strace -f gcc hello.c to caputre all system calls, which gives me the list of all the filenames needed by the compiler to compile my program (the excellent memoize script is built upon this trick)

I want to port memoize on the mac, so I need some kind of strace. What I actually need is the list of files gcc reads and writes into, so what I need is more of a truss. Sure enough can I say dtruss -f gcc hello.c and get somewhat the same functionality, but then the compiler is run with root priviledges, which is obviously undesirable (apart from the massive security risk, one issue is that the a.out file is now owned by root :-)

I then tried dtruss -f sudo -u myusername gcc hello.c, but this feels a bit wrong, and does not work anyway (I get no a.out file at all this time, not sure why)

All that long story tries to motivate my original question: how do I get dtrace to run my command with normal user privileges, just like strace does in linux ?

Edit: is seems that I'm not the only one wondering how to do this: question #1204256 is pretty much the same as mine (and has the same suboptimal sudo answer :-)

回答1:

Not an answer to your question but something to know. OpenSolaris solved this issue (partially) with "privileges" - see this page. Even in OpenSolaris, it wouldn't be possible to allow an user, without any extra privileges, to dtruss their own process. The reason is the way dtrace works - it enables probes in the kernel. So allowing a non-privileged user to probe kernel means the user can do lot of unwanted things e.g. sniffing other user's passwd by enabling probes in keyboard driver!

回答2:

The easiest way is to use sudo:

sudo dtruss -f sudo -u $USER whoami

Other solution would be to run the debugger first and monitor for new specific processes. E.g.

sudo dtruss -fn whoami

Then in another Terminal simply run:

whoami

Simple as that.

More tricky arguments you can find in the manual: man dtruss

Alternatively you can attach dtruss to the running user process e.g. on Mac:

sudo dtruss -fp PID

or similar on Linux/Unix by using strace:

sudo strace -fp PID

Another hacky trick could be to execute the command and right after that attach to the process. Here are some examples:

sudo true; (./Pages &); sudo dtruss -fp `pgrep -n -x Pages`
sudo true; (sleep 1 &); sudo dtruss -fp `pgrep -n -x sleep`
sudo true; (tail -f /var/log/system.log &); sudo dtruss -fp `pgrep -n -x tail`

Note:

first sudo is just for caching the password at the first time of running,
this trick doesn't work for quick command lines like ls, date as it takes some time untill debugger will attach to the process,
you have to type your command in two places,
you can ignore & to run the process to the background, if it's already doing that,
after finishing debugging, you'll have to manually kill the background process (e.g. killall -v tail)

回答3:

The -n argument to dtruss will cause dtruss to wait and examine processes that match the argument to -n. The -f option will still work to follow processes forked from the processes matched by -n.

All this means that if you want to dtruss a process (for the sake of argument, let's say it's whoami) running as your nonprivileged user, follow these steps:

Open a root shell
Run dtruss -fn whoami
- this will sit and wait for a process named "whoami" to exist
Open a nonprivileged shell
Run whoami
- this will execute and exit normally
Observe system call trace in dtruss window
- dtruss will not exit on its own — it will continue waiting for matching processes — so break out of it when you're done

This answer duplicates the latter part of @kenorb's response, but it deserves to be a first-class answer.

回答4:

I don't know if you can get dtruss to be as noninvasive as strace.

A variant of the "sudo [to root] dtruss sudo [back to nonroot] cmd" that seems to work better in some quick testing for me is:

sudo dtruss -f su -l `whoami` cd `pwd` && cmd....

The outer sudo is of course so dtruss runs as root.

The inner su is back to me, and with -l it recreates the environment properly, at which point we need to cd back to where we started.

I think "su -l user" is better than "sudo -u user" if you want the environment to be what that user normally gets. That'll be their login environment though; I don't know if there's a good way to let the environment inherit through the two user changes instead.

In your question, one additional complaint that you had about the "sudo dtruss sudo" workaround, other than ugliness, was that "I get no a.out file at all this time, not sure why". I don't know why either, but in my little test script, a "sudo dtruss sudo" variant also failed to write to a test output file, and the "sudo dtruss su" variant above did create the output file.

回答5:

It seems that OS X does not support using dtrace to replicate all the features of strace that you need. However, I'd suggest trying to create a wrapper around suitable syscalls. It looks like DYLD_INSERT_LIBRARIES is the environment variable you want to hack a bit. That's basically the same as LD_PRELOAD for Linux.

A much easier way of doing library function overrides is using the DYLD_INSERT_LIBRARIES environment variable (analogous to LD_PRELOAD on Linux). The concept is simple: at load time the dynamic linker (dyld) will load any dynamic libraries specified in DYLD_INSERT_LIBRARIES before any libraries the executable wants loaded. By naming a function the same as one in a library function it will override any calls to the original.

The original function is also loaded, and can be retrieved using the dlsym(RTLD_NEXT, “function_name”); function. This allows a simple method of wrapping existing library functions.

According to the example by Tom Robinson you may need to set DYLD_FORCE_FLAT_NAMESPACE=1, too.

Copy of the original example (lib_overrides.c) that overrides only fopen:

#include <stdio.h>
#include <unistd.h>
#include <dlfcn.h>

// for caching the original fopen implementation
FILE * (*original_fopen) (const char *, const char *) = NULL;

// our fopen override implmentation
FILE * fopen(const char * filename, const char * mode)
{
    // if we haven’t already, retrieve the original fopen implementation
    if (!original_fopen)
        original_fopen = dlsym(RTLD_NEXT, "fopen");

    // do our own processing; in this case just print the parameters
    printf("== fopen: {%s,%s} ==\n", filename, mode);

    // call the original fopen with the same arugments
    FILE* f = original_fopen(filename, mode);

    // return the result
    return f;
}

Usage:

$ gcc -Wall -o lib_overrides.dylib -dynamiclib lib_overrides.c
$ DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=lib_overrides.dylib command-to-test

回答6:

Disclaimer: this is derived from @kenorb's answer. It has some advantages though: PID is more specific than execname. And we can make a short-lived process wait for DTrace before it begins.

This is a bit race-conditiony, but…

Let's say we want to trace cat /etc/hosts:

sudo true && \
(sleep 1; cat /etc/hosts) &; \
sudo dtrace -n 'syscall:::entry /pid == $1/ {@[probefunc] = count();}' $!; \
kill $!

We use sudo true to make sure that we clear sudo's password prompt before we start running anything time-sensitive.

We start a background process ("wait 1 sec, then do something interesting"). Meanwhile, we start DTrace. We've captured the background process's PID into $!, so we can pass that to DTrace as an arg.

The kill $! runs after we close DTrace. It's not necessary for our cat example (process closes on its own), but it helps us end long-running background processes like ping. Passing -p $! to DTrace is the preferred way to do this, but on macOS apparently requires a code-signed executable.

The other thing you can do is to run the command in a separate shell, and snoop that shell. See my answer.