public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Josh Stone <jistone@redhat.com>
To: Pasi Savanainen <pasi.savanainen@nixu.com>
Cc: systemtap@sourceware.org
Subject: Re: [PATCH] Removed unneeded access().
Date: Wed, 13 Jun 2012 17:13:00 -0000	[thread overview]
Message-ID: <4FD8CA1D.2060508@redhat.com> (raw)
In-Reply-To: <1339588861-27950-1-git-send-email-pasi.savanainen@nixu.fi>

On 06/13/2012 05:01 AM, Pasi Savanainen wrote:
> * ctl.c: access() is not needed because previous open() will fail
> if user has no read write accees to a command channel file.

Sorry, this is not true, because staprun is setuid-root.  The open()
should always succeed if the file exists, due to the effective UID 0,
but access() is making sure that the *real* UID (of the original user)
also has permissions for that file.

Later when the control channel is opened by stapio, your statement about
open() and access() is true, but we must be careful with staprun.

> Actually existance of access() check generates a misleading error:
> "Error, 'stap_26013' (stap_26013) is not a zombie systemtap module."
> when stap is runned by regular user (stapusr group)
> and /sys/kernel/debug is mounted as 0700.

This is true - regular users won't be able to reach anything underneath
if debugfs is mounted this way.  My first thought is, "Don't do that!"

We could at least clean up the error messages though.  I think we could
just add an access("/sys/kernel/debug", X_OK) check in staprun_funcs.c
mountfs() to make sure the user will be able to get that far.

It might also be possible to solve this more fully.  We could open the
directory in staprun and do the access check with faccessat().  Then
we'd have to also pass a control_channel fd across the exec to stapio,
since it can't open that path itself.  Given the security concerns about
all this though, I'd want stronger motivation for tinkering here.

Josh

  reply	other threads:[~2012-06-13 17:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-13 12:01 Pasi Savanainen
2012-06-13 17:13 ` Josh Stone [this message]
2012-06-14  6:39   ` Pasi Savanainen
2012-06-14 21:32     ` Josh Stone

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=4FD8CA1D.2060508@redhat.com \
    --to=jistone@redhat.com \
    --cc=pasi.savanainen@nixu.com \
    --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).