All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	Paul Mackerras <paulus@samba.org>,
	Namhyung Kim <namhyung.kim@lge.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] perf tools: Fixup for removing -f option in perf record
Date: Fri, 28 Jun 2013 18:07:11 +0200	[thread overview]
Message-ID: <20130628160711.GA4389@gmail.com> (raw)
In-Reply-To: <51CDB3CB.8040304@gmail.com>


* David Ahern <dsahern@gmail.com> wrote:

> On 6/28/13 9:37 AM, Ingo Molnar wrote:
> >
> >* David Ahern <dsahern@gmail.com> wrote:
> >
> >>On 6/28/13 3:47 AM, Jiri Olsa wrote:
> >>>>>I thought -f was the implied default for ages?
> >>>>
> >>>>OK.. I've been dutifully typing it all this while :-)
> >>>
> >>>The '-f' option in record command had no affect.. myabe it got
> >>>depreceated when we started to backup perf.data to perf.data.old..?
> >>
> >>Way back in 2010, 2.6.34 kernel - 7865e817 commit. I've been typing
> >>the -f for while too. Now about the need for the pesky -f on the
> >>analysis side....
> >
> >That's only needed when perf.data is owned by a different user, right?
> >
> 
> Yes, why not let file permissions dictate of uid x can read uid y files? 
> Why does perf need to have that restriction? For example, QA collects 
> the data files, developers analyze them.

So, the thinking behind that is that user should not be able to
generate a malicious perf.data file and let root (or another user)
run it accidentally.

( That presumes some sort of exploitable parsing bug or other buffer 
  overflow in perf. )

I don't feel terribly strongly about it though.

Thanks,

	Ingo

  reply	other threads:[~2013-06-28 16:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-27  4:25 [PATCH] perf tools: Fixup for removing -f option in perf record Namhyung Kim
2013-06-27  9:36 ` Peter Zijlstra
2013-06-27 10:39   ` Ingo Molnar
2013-06-27 10:47     ` Peter Zijlstra
2013-06-28  9:47       ` Jiri Olsa
2013-06-28 14:17         ` David Ahern
2013-06-28 15:37           ` Ingo Molnar
2013-06-28 16:03             ` David Ahern
2013-06-28 16:07               ` Ingo Molnar [this message]
2013-07-09  7:41 ` Namhyung Kim
2013-07-09 14:21   ` David Ahern
2013-07-10  0:07     ` Namhyung Kim
2013-07-12  8:50 ` [tip:perf/urgent] perf record: Remove -f/--force option tip-bot for Jiri Olsa

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=20130628160711.GA4389@gmail.com \
    --to=mingo@kernel.org \
    --cc=acme@ghostprotocols.net \
    --cc=dsahern@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung.kim@lge.com \
    --cc=namhyung@kernel.org \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.