On Thu, Aug 04, 2016 at 10:13:29AM -0500, Eric W. Biederman wrote:
> The bits useful to the perf situation are:
> - user namespaces nest.
> - anyone can create a user namespace.
> - a sysctl can be bound to the userns that takes local privilege to
> change so you can't override it arbitrarily.
>
> Which is a long way of saying a user namespace is one way of marking
> processes that may or may not use perf.
>
> It was given in this case as an example of something that has been
> looked at that appears to solve peoples concerns.
> What is attractive to me semantically about something like this is
> applications that have perf_event disabled can still be traced with perf.
> > So far I'm still liking the new capability bit better, assuming I
> > understood those right.
>
> Your subsystem your call. I have never had much luck with capability
> bits. They are not particularly flexible, and are hard to get rid of
> permanently any suid root app gains them all.
Right, so I've no experience with any of this.
But from what I understood amluto recently made capabilities much more
useful with: 58319057b784 ("capabilities: ambient capabilities").
And the thing I like is having file capabilities, so even though the
user cannot in general create perf events, we could mark the
/usr/bin/perf executable as having CAP_PERF and allow it to create them,
because its a 'trusted' executable.
Can something like that be done with userns? Afaiu once you create a
userns with perf disabled, even a nested one cannot re-enable it,
otherwise you cannot create sandboxes.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
