linux-kernel - [PATCH v2] perf tools: do not complain if root is owning perf.data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090827075902.GF19653@laphroaig.corp>
Date:	Thu, 27 Aug 2009 09:59:02 +0200
From:	Pierre Habouzit <pierre.habouzit@...ersec.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org, stable@...nel.org
Subject: [PATCH v2] perf tools: do not complain if root is owning perf.data

This improves patch fa6963b24 so that perf.data stuff that has been dumped
as root can be read (annotate/report) by a user without the use of the
--force.

Rationale is that root has plenty of ways to screw us (usually) that do
not require twisted schemes involving specially crafting a perf.data.

Signed-off-by: Pierre Habouzit <pierre.habouzit@...ersec.com>
Cc: Ingo Molnar <mingo@...e.hu>
Cc: Paul Mackerras <paulus@...ba.org>,
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Cc: <stable@...nel.org>
---
    On Wed, Aug 26, 2009 at 08:24:59PM +0200, Ingo Molnar wrote:
    > Ok, this makes sense - but i think we should do this in .32 only, 
    > with a Cc: <stable@...nel.org> backport tag for .31.1.

    You're the boss ;)

    > Mind doing it against the latest perfcounters tree, which can be 
    > found in -tip:
    > 
    >   http://people.redhat.com/mingo/tip.git/README
    > 
    > your current version does not apply cleanly as the surrounding code 
    > has changed a bit already.

    Here it is, against perfcounters/core which I assume is the proper
    tip branch. Note that I'd suggest adding a README.Devel under
    tools/perf to explicit how patches should be submitted, at least to
    explain against which tree it's best to do our patches for
    submission, it could help people avoiding losing your time with
    unnecessary back-and-forth mails just to rebase a patch ;)

 tools/perf/builtin-annotate.c |    4 ++--
 tools/perf/builtin-report.c   |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 4ac618b..4c7bc44 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -984,8 +984,8 @@ static int __cmd_annotate(void)
 		exit(-1);
 	}
 
-	if (!force && (input_stat.st_uid != geteuid())) {
-		fprintf(stderr, "file: %s not owned by current user\n", input_name);
+	if (!force && input_stat.st_uid && (input_stat.st_uid != geteuid())) {
+		fprintf(stderr, "file: %s not owned by current user or root\n", input_name);
 		exit(-1);
 	}
 
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index d2e2882..ea6328a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -1405,8 +1405,8 @@ static int __cmd_report(void)
 		exit(-1);
 	}
 
-	if (!force && (input_stat.st_uid != geteuid())) {
-		fprintf(stderr, "file: %s not owned by current user\n", input_name);
+	if (!force && input_stat.st_uid && (input_stat.st_uid != geteuid())) {
+		fprintf(stderr, "file: %s not owned by current user or root\n", input_name);
 		exit(-1);
 	}
 
-- 
1.6.4.1.341.gf2a44

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/