On Wed, Oct 15, 2008 at 11:37:13AM -0700, Edward Peschko wrote: > ok.. I understand the intent, but that doesn't really help in many > situations. I, too, can have my own setup at home (and give myself > what I want) but I can't set up the whole development environment that > I'm working on offsite, limiting the troubleshooting usefulness of > dtrace.
In such situations the thing to do is to work with a sysadmin who will review and run your scripts on your behalf. It's what we do. When posters on [EMAIL PROTECTED], say, need help and we need more information we often send them DTrace scripts to run, and they send us back the output (check the archives). We don't ask for privileged (or any) access to customers' systems! Yet we manage to get the data that we need. > I guess I'm looking for a way to look into the kernel state without > necessarily being able to look into *all* kernel state - ie: > selectively for all processes that I control. > > I don't know how feasible something like this would be, but it would > be extremely useful for lots of larger development environments. I can imagine things that could be done to create a crippled dtrace_kernel, but it would be very difficult to convince anyone that those things are enough to prevent privilege escalation. And the result would likely be too constrained for your purposes anyways. Which means there'd be no upside to putting any effort into such a project. Nico -- _______________________________________________ dtrace-discuss mailing list [email protected]
