Masami Hiramatsu <mhiramat@redhat.com> writes:
[...]
Second, it is part of enabling unprivileged users to run systemtap
scripts that are severely restricted (no kernel probes; only probes on
one's own processes; that sort of thing). (Allowing an unprivileged
user to build his own kernel modules via gcc etc., opens up too many
possibilities for subversion of the constraints.)
I think this is also the issue of systemtap itself, not only
compiler server, because it is a run-time privilege issue.
It is *both*. A sysadmin may want to permit an unprivileged user to
run systemtap scripts, but only if they are built by a trusted
toolchain (so that it will compile in the proper constraints). Such a
user cannot be build a trustworthy .ko himself -- after all, there is
no proof that any old .ko was even created by systemtap.
[...] IMHO, ssh is better approach, because it becomes the basic
function for remote access now, so we may not need to setup
something special on the server and the client.
While ssh could conceivably operate as the wire transport layer, we
still need something above it to (a) bundle any tapsets requested by
the end-user via -Ipath/ flags; (b) invoke the toolchain in a
trustworthy (unmodifiable) manner; (c) cause the resulting module to
be reliably crypto-signed; (d) get back all the results - .c/.ko,
stdout/stderr, exit-rc. A plain "ssh SERVER stap -p4 ..." wouldn't
accomplish these.
- FChE