[lkml]   [2005]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.11-rc3-mm2
Nick Piggin wrote:
> On Thu, 2005-02-10 at 18:09 -0800, Matt Mackall wrote:
>>On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
>>>* Matt Mackall ( wrote:
>>>>What happened to the RT rlimit code from Chris?
>>>I still have it, but I had the impression Ingo didn't like it as a long
>>>term solution/hack (albeit small) to the scheduler. Whereas the rt-lsm
>>>patch is wholly self-contained.
>>I think it's important to recognize that we're trying to address an
>>issue that has a much wider potential audience than pro audio users,
>>and not very far off - what is high end audio performance today will be
>>expected desktop performance next year.
>>So I think it's critical that we find solution that's appropriate for
>>_every single box_, because realistically vendors are going to ship
>>with this "wholly self-contained" feature turned on by default next
>>year, at which point the "containment" will be nil and whatever warts
>>it has will be with us forever.
>>The rlimit stuff is not perfect, but it's a much better fit for the
>>UNIX model generally, which is a fairly big win. Having it in the
>>system unconditionally doesn't trigger the gag reflex in quite the
>>same way as the LSM approach.
> Without considering the userspace aspect, RT rlimits is the best
> implementation I have seen. All others either break RT scheduling
> semantics, or don't allow any way for root to maintain control of
> the system after giving out RT privileges.

Personally, I think that the best approach to solving this problem is
from the privileges aspect. The ability to grant privileges to only set
RT policy is just an example of a general need for granting limited
privileges to a program and/or a user. So a solution that involved a
mechanism for granting a specified subset of root privileges to
specified users when running specified programs would have wider

My limited understanding of SELinux (which may be mistaken) is that it
provides a basic framework for this level of privilege control and
perhaps the solution lies there.

Peter Williams

"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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:10    [W:0.049 / U:3.264 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site