[Bug tapsets/13693] New: make probefunc unprivileged

[Bug tapsets/13693] New: make probefunc unprivileged

[fche at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13693

             Bug #: 13693
           Summary: make probefunc unprivileged
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap@sourceware.org
        ReportedBy: fche@redhat.com
    Classification: Unclassified


probefunc/probemod have had a funny history as to where they try to get
function name strings from.  The probe-point-parsing variant is depended
upon from the para-callgraph* examples, and that part could be well enough
unprivileged.  Other usages dip into the equivalent symdata(), which is
(rightfully?) privileged.

We should not so intermingle these.  We could deprecate the privileged
parts of probefunc(), so that in 1.8+, unprivileged scripts can use it
(for probe-point-parsing only, or some cleaner equivalent).  Or we could
write a new function to do only that, and adjust sample scripts.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/13693] make probefunc unprivileged

[mjw at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13693

Mark Wielaard <mjw at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjw at redhat dot com

--- Comment #1 from Mark Wielaard <mjw at redhat dot com> 2012-02-15 12:01:14 UTC ---
Should we just recommend pn() and pp() which are unprivileged?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/13693] make probefunc unprivileged

[fche at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13693

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> 2012-02-15 12:23:54 UTC ---
> Should we just recommend pn() and pp() which are unprivileged?

Not so simple; for para-callgraph*, we don't want boilerplate
substrings of the pp/pn(), just the plain function names.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/13693] make probefunc unprivileged

[smakarov at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13693

Serguei Makarov <smakarov at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |smakarov at redhat dot com
         Resolution|                            |FIXED

--- Comment #3 from Serguei Makarov <smakarov at redhat dot com> 2012-09-28 19:47:06 UTC ---
Building on tapset improvements from PR6580, I implemented a preprocessor
conditional of the form %( systemtap_privilege == "privileged" / "unprivileged"
%? ... %: ... %). The probefunc() implementation now wraps all kernel-space
retrieval code in such a conditional, eliding it when compiled with a lower
privilege, while leaving the user-space code available.

This allows unprivileged use of probefunc() handily, while retaining backwards
compatibility with its kernel-space uses for privileged scripts (no
deprecation/rewriting necessary). For instance, para-callgraph* and such can
now be run in unprivileged mode, so long as the probe points they're handed are
appropriate of course.

It remains to document the new systemtap_privilege check in order to make it
available and documented if we want to consider it for similar uses in the
future. (i.e. for having a tapset function provide a subset of the normal
functionality in unprivileged mode)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.