public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "dsmith at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug runtime/15408] procfs probes broken on rawhide
Date: Tue, 07 May 2013 16:32:00 -0000	[thread overview]
Message-ID: <bug-15408-6586-fugKlzfT6c@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-15408-6586@http.sourceware.org/bugzilla/>

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.

  parent reply	other threads:[~2013-05-07 16:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-26 17:22 [Bug runtime/15408] New: " dsmith at redhat dot com
2013-04-26 17:28 ` [Bug runtime/15408] " dsmith at redhat dot com
2013-04-30 16:25 ` dsmith at redhat dot com
2013-05-02 16:04 ` dsmith at redhat dot com
2013-05-07 15:38 ` dsmith at redhat dot com
2013-05-07 15:40 ` fche at redhat dot com
2013-05-07 16:32 ` dsmith at redhat dot com [this message]
2013-05-07 21:23 ` dsmith at redhat dot com
2013-05-09 23:10 ` jistone at redhat dot com
2013-05-10 14:10 ` dsmith at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-15408-6586-fugKlzfT6c@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).