How does embedded C + annotations + privileges really play together?

How does embedded C + annotations + privileges really play together?

[Petr Muller]

Hi,

I've been playing with embedded C in systemtap probes, and by studying
stap manpage (the version in F16) some things are not clear to me. It
seems that to use embedded C, one needs to *always* use guru mode.

Seems logical, but then there follows a description of "The embedded-C
code may contain markers to ...", which contains stuff like '/*
unprivileged */' and '/* guru */'. The first one says that with these
annotations it should be possible to use embedded C even as a
unprivileged user, and the second one seems simply redundant.

However, my experiments with stap server seem to refuse -g and
--privilege=stapusr options togetger.

Could anyone clarify how and if these annotations should really work?

Thanks,
-- 
Petr Muller

Re: How does embedded C + annotations + privileges really play together?

[Frank Ch. Eigler]

Petr Muller <muller@redhat.com> writes:

> Seems logical, but then there follows a description of "The embedded-C
> code may contain markers to ...", which contains stuff like '/*
> unprivileged */' and '/* guru */'. The first one says that with these
> annotations it should be possible to use embedded C even as a
> unprivileged user, and the second one seems simply redundant.

The /* guru */ markup is useful in embedded-C functions in the tapset.
Normally, embedded-C code in the tapset is allowed to be called,
without stap -g guru mode, because it is presumed to be
safely/competently written.  These are usually for direct invocation
from within the tapset handlers themselves.

Such functions may not be invoked from --privilege=stapusr mode at
all, unless they are instead marked /* unprivileged */.  These

Re: How does embedded C + annotations + privileges really play together?

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/30/2012 04:30 PM, Frank Ch. Eigler wrote:
> Petr Muller <muller@redhat.com> writes:
> 
>> Seems logical, but then there follows a description of "The
>> embedded-C code may contain markers to ...", which contains stuff
>> like '/* unprivileged */' and '/* guru */'. The first one says
>> that with these annotations it should be possible to use embedded
>> C even as a unprivileged user, and the second one seems simply
>> redundant.
> 
> The /* guru */ markup is useful in embedded-C functions in the
> tapset. Normally, embedded-C code in the tapset is allowed to be
> called, without stap -g guru mode, because it is presumed to be 
> safely/competently written.  These are usually for direct
> invocation from within the tapset handlers themselves.

An example of restricting callers via /* guru */ use in tapsets can be
found in guru-delay.stp:

  30 function mdelay(ms:long) %{
  31   /* guru */
  32   mdelay(THIS->ms);
  33 %}

This restricts the use of the tapset to competent users (or at least:
users the administrator believes to be competent ;).

Regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/GQ9AACgkQ6YSQoMYUY95j1ACgsz/YzePHJc9KuSEg4lxn6cyQ
V5IAn0da26xiRtuody1iuP0yva77Opt/
=kUUF
-----END PGP SIGNATURE-----

Re: How does embedded C + annotations + privileges really play together?

[Frank Ch. Eigler]

I wrote, incompletely:

> The /* guru */ markup is useful in embedded-C functions in the tapset.
> Normally, embedded-C code in the tapset is allowed to be called,
> without stap -g guru mode, because it is presumed to be
> safely/competently written.  These are usually for direct invocation
> from within the tapset handlers themselves.

I meant to add:

They are safe to call with valid input, though may expose private
data.  Because of these presumptions, unprivileged users may not run
them.  Privileged users may, but need to be careful.

Contrast this with embedded-C functions declared with /* guru */.
They are unsafe for general use, even by privileged users.  They are
only intended for special cases and/or expert users, requiring stap -g.


> Such functions may not be invoked from --privilege=stapusr mode at
> all, unless they are instead marked /* unprivileged */.  These

I meant to continue:

... functions are unusually robustly written, with the possibility in
mind that inputs are malevolent.  (It would not make sense to mark
an embedded-C function both /* guru */ and /* unprivileged */, in the
same way it doesn't make sense to run "stap -g --privilege=stapusr".


- FChE