* Peter Williams <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
"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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
