This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: New Probe Points for Unprivileged Users
- From: David Smith <dsmith at redhat dot com>
- To: Dave Brolley <brolley at redhat dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>
- Date: Fri, 11 Sep 2009 10:20:12 -0500
- Subject: Re: New Probe Points for Unprivileged Users
- References: <4AA95682.5000605@redhat.com>
On 09/10/2009 02:41 PM, Dave Brolley wrote:
> Hi,
>
> Support for limited probing by unprivileged users (not root, stapdev or
> stapusr) was recently pushed to our git sources (see the NEWS file). The
> number and type of probe points available to these users has
> intentionally been restricted in the early stages of development and
> testing.
>
> Overall, the philosophy is that an unprivileged user should not be able
> to use systemtap to affect the system in ways they would not normally be
> able to or to obtain information that they would not normally be able to
> obtain.
...
> I would like to expand the list of available probes to include the
> remainder of the process.* probes where, once again, probes are
> restricted to the user's own processes. Before doing so, I just wanted
> to double check that this would not be exposing anything in violation of
> the philosophy mentioned above. If you see any problems with exposing
> the probe points below to unprivileged users, for their own processes,
> then please let me know.
I'll comment on the ones I'm familiar with. The thread.begin/thread.end
variants should be fine when restricted to the user's own processes.
They are very similar to the process begin/end probes you've already
allowed. Specifically, I'm talking about the following:
> process.thread.begin
> process.thread.end
> process("xxx").thread.begin
> process("xxx").thread.end
> process(N).thread.begin
> process(N).thread.end
The syscall variants should also be fine when restricted to the user's
own processes. They will slow down the target task, but since they will
be the user's own processes that should be fine. They shouldn't reveal
any more information than running 'strace' on a process would. If that
level of information is OK, then the syscall variants should be OK.
> process.syscall
> process.syscall.return
> process("xxx").syscall
> process("xxx").syscall.return
> process(N).syscall
> process(N).syscall.return
Next we have the 'insn' probe variants. Like the syscall probes, they
will slow down the target task. They can provide information similar to
what a user could get by using gdb to single-step his own process. If
that level of information is OK, then the insn probe variants should be OK.
> process("xxx").insn
> process("xxx").insn.block
> process(N).insn
> process(N).insn.block
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)