This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: run-stap vs -c
Roland McGrath wrote:
> It believing it's not setuid is also necessary for it to obey the
> environment variables, which is key.
Err, oops! I happened to have it installed too, so I didn't notice that
I had broken that.
> How about we just teach staprun to set the channel to a different uid?
> i.e., just take switches for the uid/gid to own the channel pseudofiles,
> defaulting to getuid()/getgid(). The run-staprun wrapper can pass
> $SUDO_UID and $SUDO_GID here.
>
> That might even be a real feature in the long run, to have a
> more-privileged admin thing that can decide to install a module, but have
> stapio (and its permissions for output-writing, etc.) run in some other
> chosen identity that isn't the same one that invokes staprun and doesn't
> have to have permission to run staprun.
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.
>> 3. If staprun sees UID=EUID=0, then still skip the permission checks.
>> After that, check getenv("STAP_REAL_UID") and if set call setuid(), so
>> the control channel perms will match the UID and non-root stapio can
>> open it.
>
> That is about like what I proposed above.
>
>> But I'm even more wary of modifying staprun, for fear of introducing a
>> hole in its security checks...
>
> The staprun options I mentioned above would have that can of worms. In the
> conservative version that you suggested here, the only new code would be in
> the path where the security checks are disabled already.
Ok, I pushed a new version that takes this conservative route.
Hopefully all bases are covered this time... :)
Josh