Messages in this thread | | | From | John Stultz <> | Date | Wed, 13 Jul 2016 16:47:15 -0700 | Subject | Re: [PATCH 2/2] proc: Add /proc/<pid>/timerslack_ns interface |
| |
On Tue, Feb 16, 2016 at 5:06 PM, John Stultz <john.stultz@linaro.org> wrote: > This patch provides a proc/PID/timerslack_ns interface which > exposes a task's timerslack value in nanoseconds and allows it > to be changed. > > This allows power/performance management software to set timer > slack for other threads according to its policy for the thread > (such as when the thread is designated foreground vs. background > activity) > > If the value written is non-zero, slack is set to that value. > Otherwise sets it to the default for the thread. > > This interface checks that the calling task has permissions to > to use PTRACE_MODE_ATTACH_FSCREDS on the target task, so that we > can ensure arbitrary apps do not change the timer slack for other > apps.
Sigh.
So I wanted to pull this thread up again, because when I originally proposed upstreaming the PR_SET_TIMERSLACK_PID feature from the AOSP common.git tree, the first objection from Arjan was that it only required CAP_SYS_NICE: http://lkml.iu.edu/hypermail/linux/kernel/1506.3/01491.html
And reasonably, setting timerslack to very large values does have the potential to effect applications much further then what a task could do previously with CAP_SYS_NICE.
CAP_SYS_PTRACE was suggested instead, as that allows applications to manipulate other tasks more drastically.
(At the time, I checked with some of the Android developers, and got no objection to changing to use this capability.)
However, after submitting the changes to Android required to support the upstreamed /proc/<tid>/timerslack_ns interface, I've gotten some objections with adding CAP_SYS_PTRACE to the system_server, as this would allow the system_server to be able to inspect and modify memory on any task in the system. This gives the system_server privileged to effect applications much further then what it could do previously.
So I worry I'm a bit stuck here. For general systems, CAP_SYS_NICE is too low a level of privilege to set a tasks timerslack, but apparently CAP_SYS_PTRACE is too high a privilege for Android's system_server to require just to set a tasks timerslack value.
So I wanted to ask again if we might consider backing this down to CAP_SYS_NICE, or if we can instead introduce a new CAP_SYS_TIMERSLACK or something to provide the needed in-between capability level.
Thoughts?
thanks -john
| |