[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200224132905.32sdpbydnzypib47@e107158-lin.cambridge.arm.com>
Date: Mon, 24 Feb 2020 13:29:06 +0000
From: Qais Yousef <qais.yousef@....com>
To: Parth Shah <parth@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org, peterz@...radead.org,
mingo@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, chris.hyser@...cle.com,
patrick.bellasi@...bug.net, valentin.schneider@....com,
David.Laight@...LAB.COM, pjt@...gle.com, pavel@....cz,
tj@...nel.org, dhaval.giani@...cle.com, qperret@...gle.com,
tim.c.chen@...ux.intel.com
Subject: Re: [PATCH v4 4/4] sched/core: Add permission checks for setting the
latency_nice value
On 02/24/20 14:29, Parth Shah wrote:
> Since the latency_nice uses the similar infrastructure as NICE, use the
> already existing CAP_SYS_NICE security checks for the latency_nice. This
> should return -EPERM for the non-root user when trying to set the task
> latency_nice value to any lower than the current value.
>
> Signed-off-by: Parth Shah <parth@...ux.ibm.com>
I'm not against this, so I'm okay if it goes in as is.
But IMO the definition of this flag is system dependent and I think it's
prudent to keep it an admin only configuration.
It'd be hard to predict how normal application could use and depend on this
feature in the future, which could tie our hand in terms of extending it.
I can't argue hard about this though. But I do feel going further and have
a sched_feature() for each optimization that uses this flag could be necessary
too.
Thanks
--
Qais Yousef
> ---
> kernel/sched/core.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index e1dc536d4ca3..f883e1d3cd10 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4887,6 +4887,10 @@ static int __sched_setscheduler(struct task_struct *p,
> return -EINVAL;
> if (attr->sched_latency_nice < MIN_LATENCY_NICE)
> return -EINVAL;
> + /* Use the same security checks as NICE */
> + if (attr->sched_latency_nice < p->latency_nice &&
> + !can_nice(p, attr->sched_latency_nice))
> + return -EPERM;
> }
>
> if (pi)
> --
> 2.17.2
>
Powered by blists - more mailing lists