Re: stap vs pgrps

[Josh Stone <jistone at redhat dot com>]

Mark Wielaard wrote:
> On Tue, 2009-03-31 at 20:16 -0700, Roland McGrath wrote:
>>> That's why I do think stap needs to care, rather than trying to pass the
>>> buck up to the caller.
>> stap is a command-line batch-style program like any other.  It is not
>> expected to deal with this for you.  That is just the Unix way.  The
>> thing that runs it and wants to send it a SIGTERM is *just wrong* for
>> running any normal command-line batch-style program.
>>
>> If you are a non-batch thing that runs and controls a batch thing, then you
>> are responsible for the fancy magic that "controls" really means.  i.e.,
>> you are a job control shell or run one, as inside "expect" or any terminal
>> window sort of thing.  (Those use a pty, which is also the only way to be
>> right in the face of potential privilege issues.)
> 
> But I don't think users see stap as a batch thing, they see it as that
> program that provides them the output they want to read interactively.
> If they kill/interrupt it, then they expect it to die and clean up after
> itself. You expect the same from a python or perl script that you run,
> won't you?

Agreed.  It may not be the Unix way, but if someone kills stap, they
probably want it all cleaned up too, so let's just DWIM.

>> When you have a setuid program you might need to kill, this is really all
>> moot.  You don't have to agree with me.  You just can't do it any other
>> way.  You're not allowed.  (Find a GUI program that runs "ping" and see
>> whether it does some magic or whether it's actually just broken, 'cause
>> those are the only two options.)
>> [...]
>> If one cares about being robust during the "staprun" phase, then this
>> really is all moot.  It's setuid and the stap process is not allowed to
>> send it any signals with kill.
> 
> So, this is basically the original problem statement. Being robust
> during the staprun phase. That is what we care about. If someone kills
> stap during normal interactive running it (either from a shell, an
> external program or a quick and dirty script) we want staprun to
> 
> Should we turn all this around? Add a "--watch-parent" argument to
> staprun (or maybe --controller <pid>), so that staprun monitors that
> process (which normally will just be the interactive stap program) and
> then when that process dies for whatever reason cleans up silently.

It's actually only a small window under the setuid staprun, and then we
exec to stapio as the original user, so I don't think we should worry
about special mechanisms here.

The run-stap script gets this wrong though -- it runs staprun with sudo,
then stapio keeps it's root UID, as does any -c command and script
system() calls.  It would be better for us to pass in a STAP_UID/GID for
the original id.  (I know about SUDO_UID/GID, but I don't want to tamper
with someone running stap in sudo'ed shell.)

I also agree with Roland's suggestion that we should exec staprun
anyway, so I'll look into moving pass-5 cleanup into stapio...

Josh