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]

[Bug runtime/15408] procfs probes broken on rawhide


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

--- Comment #6 from David Smith <dsmith at redhat dot com> 2013-05-07 16:32:50 UTC ---
Thinking about this some more, here's what's going on.

staprun (which is setuid 0) loads the module. At this point the following call
chain occurs:

  init_module() ->
   _stp_transport_init() ->
     _stp_transport_data_fs_start() ->
       _stp_lock_transport_dir()

So, while staprun is running our euid is 0. We can lock the transport
directory, which really just creates a debugfs directory.

Then staprun execs stapio.

stapio (which isn't a setuid program) sends STP_START, which eventually calls
the module's 'systemtap_module_init()' function. During systemtap_module_init()
when there are procfs probes, we call _stp_lock_transport_dir(). At this point,
since our euid isn't 0, we can't create the debugfs directory.

Note that procfs probes don't really need to lock the transport directory. This
was done so that simultaneously running systemtap modules don't create multiple
/proc/systemtap directories (which the proc file system doesn't disallow).

To fix this problem, we can try to change our euid back to 0 or we could come
up with a different method of handing simultaneously running systemtap modules
trying to create the /proc/systemtap directory. The latter sounds safer.

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


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