linux-kernel - [BUG] perf record: --uid=x fails

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-next>] [day] [month] [year] [list]

Date:	Mon, 14 Jan 2013 15:14:02 +0100
From:	Stephane Eranian <eranian@...gle.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Namhyung Kim <namhyung.kim@....com>, Jiri Olsa <jolsa@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	"mingo@...e.hu" <mingo@...e.hu>
Subject: [BUG] perf record: --uid=x fails

Hi,

I was trying to use the --uid option of perf record but it fails for
me no matter
what I tried. Looks like the goal of this option is to measure ALL the processes
owned by the specified uid. Each process is measured in per-thread mode.

However for me it failed on all my attempts when running with 3.8.0-rc3 on
Ubuntu Quantal.

$ perf record --uid=eranian sleep 4
Error:
Permission error - are you root?
Consider tweaking /proc/sys/kernel/perf_event_paranoid:
 -1 - Not paranoid at all
  0 - Disallow raw tracepoint access for unpriv
  1 - Disallow cpu events for unpriv
  2 - Disallow kernel profiling for unpriv
sleep: Terminated

You don't want to be root to run this command.  Should not require
to measure the processes I own. So the error message is confusing
here.

After some debugging, I came to the conclusion that this command
fails when it hits the sshd daemon:

eranian   2439  0.0  0.0 110424  1968 ?        S    15:07   0:00 sshd:
eranian@.../2
root      2301  0.0  0.0 110424  4420 ?        Ss   15:07   0:00 sshd:
eranian [priv]

I mean the sshd process owned by me. It is owned by me but I cannot attached
an event to it. I get EACCES and I suspect it's because of missing
ptrace privilege.
The sshd binary is obviously not setuid. So there is something else preventing
ptrace. In fact, even strace -p 2349 fails. Looked online and there
were a couple
of mentions to the Yama security model and the ptrace_scope sysctl
control. I tried
that and it did not help.

So looks to me that something is broken somewhere. If the kernel
restrictions are
normal, then I think perf record should warn that it has to skip the
sshd process and
continue with the other processes owned by me. That  seems more useful than the
current situation. But I may be missing something here. If so please
explain to me.

Thanks.
--
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/