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: New Probe Points for Unprivileged Users


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)


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