Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

From: Peter Williams
Date: Mon Jan 31 2005 - 18:07:02 EST


Ingo Molnar wrote:
* Peter Williams <pwil3058@xxxxxxxxxxxxxx> wrote:


As I understand this (and I may be wrong), the intention is that if a
task has its RT_CPU_RATIO rlimit set to a value greater than zero then
setting its scheduling policy to SCHED_RR or SCHED_FIFO is allowed.


correct.


This causes me to ask the following questions:

1. Why is current->signal->rlim[RLIMIT_RT_CPU_RATIO].rlim_cur being used in setscheduler() instead of p->signal->rlim[RLIMIT_RT_CPU_RATIO].rlim_cur?

2. What stops a task that had a non zero RT_CPU_RATIO rlimit and
changed its policy to SCHED_RR or SCHED_FIFO from then setting
RT_CPU_RATIO rlimit back to zero and escaping the controls? As far as
I can see (and, once again, I may be wrong) the mechanism for setting
rlimits only requires CAP_SYS_RESOURCE privileges in order to increase
the value.


you are right, both are bugs.

i've uploaded the -D6 patch that should have both fixed:

http://redhat.com/~mingo/rt-limit-patches/


I've just noticed what might be a bug in the original code. Shouldn't the following:

if ((current->euid != p->euid) && (current->euid != p->uid) &&
!capable(CAP_SYS_NICE))

be:

if ((current->uid != p->uid) && (current->euid != p->uid) &&
!capable(CAP_SYS_NICE))

I.e. if the real or effective uid of the task doing the setting is not the same as the uid of the target task it is not allowed to change the target task's policy unless it is specially privileged.

Peter
--
Peter Williams pwil3058@xxxxxxxxxxxxxx

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/