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

[Peter Williams <pwil3058@bigpond.net.au>]

Ingo Molnar wrote:
> * Peter Williams <pwil3058@bigpond.net.au> 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@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce