Currently with staprun's setuid invocation, it will drop back to the real UID/GID that invoked it before running stapio. However, for some administrative uses, it may be useful for the data collection to run under some other UID/GID (which may not even have permission to run staprun). Commit b516e13a allows this to some extent, so that a sudo staprun can still drop permissions before running stapio. We could carefully extend this privilege to setuid invocations as well, perhaps allowed by a new stap group (stapadm?). NB: Such a granted privilege would effectively be the same as a password-free, unrestricted sudo, given stapio's -c option and the runtime's system() call. That may be no worse than what stapdev lets one do with arbitrary kernel modules, but this new privilege would be even easier to exploit. See also: http://sources.redhat.com/ml/systemtap/2009-q2/msg00065.html http://sources.redhat.com/ml/systemtap/2009-q2/msg00104.html
I would hesitate to open up one more iota of attack surface just to make run-stap.sh more cozy to operate.
(In reply to comment #1) > I would hesitate to open up one more iota of attack surface > just to make run-stap.sh more cozy to operate. Actually, run-stap is happy the way it is. This is a more general feature that "real" stap users might want, which Roland suggested while we were fixing up run-stap.
no recent/moving use case offered