This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: run-stap vs -c
Roland McGrath wrote:
>> $ sudo usermod -a -G stapdev roland
>>
>> Voila.
>
> Bzzt. Not meeting the problem spec. That's what the sudo is for.
> NO KIND OF INSTALLATION OR SYSTEM SETUP BEFORE YOU USE IT!
>
>> In this model, the /sys/debug/... channel is owned by me, and the
>> stapio runs as me. The sudo in this case is only being used to emulate
>> what setuid would have done, and all the normal permission checks in
>> staprun still apply.
>
> That is not the mandate for the feature, sorry.
> sudo is the only thing deciding your permissions,
> or you are not implementing what we're here for.
Ok, I was approaching it as just "allow a non-setuid staprun", but to
also skip the group setup is a bit trickier.
If staprun sees that UID!=EUID, then that looks like a setuid
invocation, so it must do all of its permission checks. So to bypass
the checks, run-stap has to invoke staprun with UID=EUID=0 (which is
what you had).
In that case, the control channel has root-only perms. I see two ways
for a non-root stapio to get at it:
1. Let run-stapio open the channel, set UID=EUID!=0, and pass the fd# as
a stapio argument or environment variable.
2. Let run-stapio leave EUID=0 and set UID!=0 (which is what you had).
Then after stapio opens the control channel, it can notice that
UID!=EUID and so call setresuid to drop permissions.
Both of those require modifying stapio, but #1 seems a little safer to
me. Thoughts? Other possibilities?
Josh