linux-kernel - Re: perf top -u <uid> does not seem to be working

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: <20131113175931.GC14758@ghostprotocols.net>
Date:	Wed, 13 Nov 2013 14:59:31 -0300
From:	Arnaldo Carvalho de Melo <acme@...radead.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	linux-kernel@...r.kernel.org, David Ahern <dsahern@...il.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Frédéric Weisbecker <fweisbec@...il.com>
Subject: Re: perf top -u <uid> does not seem to be working

Em Wed, Nov 13, 2013 at 12:22:49AM +0100, Ingo Molnar escreveu:
> Hm, this is unexpected I think:
> 
>   hubble:~> perf top --stdio -u mingo
>   Error:
>   You may not have permission to collect stats.
>   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
> 
>   hubble:~> cat /proc/sys/kernel/perf_event_paranoid 
>   -1
> 
> (perf is the latest version from tip:perf/core)

https://lkml.org/lkml/2012/1/26/142

Fell thru the cracks, summary:

> > > +++ b/kernel/events/core.c
> > > @@ -2636,7 +2636,8 @@ find_lively_task_by_vpid(pid_t vpid)
> > >  	/* Reuse ptrace permission checks for now. */
> > >  	err = -EACCES;
> > > -	if (!ptrace_may_access(task, PTRACE_MODE_READ))
> > > +	if (perf_paranoid_tracepoint_raw() &&
> > > +	    !ptrace_may_access(task, PTRACE_MODE_READ))
> > >  		goto errout;
> > >  	return task;

> > > ptrace_may_access(task, PTRACE_MODE_READ) fails for some tasks 
> > > owned by the user because, IIRC, in __ptrace_may_access:

> > Which tasks are these, are they privileged in any sense?

> IIRC one of them was a child of sshd, that runs as root and then changes
> the child ownership to the user logging in.

- Arnaldo
--
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/