Re: [PATCH] [request for inclusion] Realtime LSM

From: Peter Williams
Date: Tue Mar 08 2005 - 01:31:06 EST

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

I don't object to rlimits per se and I think that they are useful but
not as a sole solution to this problem. Being able to give a task
preferential treatment is a permissions issue and should be solved as

Having RT cpu usage limits on tasks is a useful tool to have when
granting normal users the privilege of running tasks as RT tasks so
that you can limit the damage that they can do BUT the presence of a
limit on a task is not a very good criterion for granting that

i think you are talking about my rlimit patch (the 'RT CPU limit' patch)
- but that one is not in discussion here.

what is being discussed currently is the other rlimit patch (from Chris
Wright and Matt Mackall) which implements a simple rlimit ceiling for
the RT (and nice) priorities a task can set. The rlimit defaults to 0,
meaning no change in behavior by default. A value of 50 means RT
priority levels 1-50 are allowed. A value of 100 means all 99 privilege
levels from 1 to 99 are allowed. CAP_SYS_NICE is blanket permission.
It's all pretty finegrained and and it's a quite straightforward
extension of what we have today.

OK. My misunderstanding.

But the patch you describe still seems a little loose to me in that it doesn't control both which users AND which programs they can run. Although I suppose that can be managed by suitable setting of file permissions?

Also I presume that root privileges are needed to set the rlimits which means that the program has to be setuid root or run from a setuid root wrapper. In the first of these cases the program will be running for a (hopefully) short while with way more privilege than it needs. This is why I'm attracted to mechanisms that allow programs to be given a subset of root's privileges and only for specified users.

I would be nice to have a solution to this particular problem that fits in with such a generalized "granular" privilege mechanism (when/if such a mechanism becomes available in the future) rather than a quirky fix that is specific to this problem and doesn't generalize well to similar problems when they arise in the future. However, I agree with your opinion that granting CAP_SYS_NICE is dangerous without some limit on the priority levels is dangerous and think that a generalized "granular" privilege mechanism would need to include such restrictions.

The patch does not attempt to do any
"damage control" of abuse caused by RT tasks, and is hence much simpler
than my patch or Con's SCHED_ISO patch. ("damage control" could be done
from userspace anyway)

Yes. In kernel "damage control" is an optional extra not a necessity with this solution. Not so sure about with the RT LSB solution though.

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
Please read the FAQ at