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
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/