Re: run-stap vs -c

[Roland McGrath <roland at redhat dot com>]

> We can certainly consider such a feature in the future.  If stapio's UID
> can't run staprun though, then the initial staprun will have to stick
> around to do the unload when stapio exits.

Good point.  In fact, that model is probably a better match for what an
admin policy along these lines would want to see.  i.e., "staprun" defines
the beginning and end of a "tracing session", which is the privileged "data
producer".  stapio is the unprivileged "data consumer" that reads it.

For tying this into a more complex admin and security/audit setup, having
the life of staprun map to the life of the tracing session (e.g. having it
wrapped in PAM hooks or whatnot) probably fits the structure they like.

Anyway, this is just noodling for the future.  I think the point we really
want to keep in mind about this is to keep the innards granular in a way
that keeps it easy to recombine in a variety of ways.  

The only thing along those lines I think it might make sense to do nowish
is replace stapio's use of SYSTEMTAP_STAPRUN with an explicit switch for
"exec this command at exit".  In current practice, staprun would pass
"$SYSTEMTAP_STAPRUN -d $MODNAME" there.  For decomposed use in other
scripts or whatnot in the future, the switch might not be used, leaving the
cleanup responsibility to whatever it was that ran stapio.


Thanks,
Roland