This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]