Messages in this thread | | | Date | Fri, 11 Feb 2005 14:26:14 +1100 | From | Peter Williams <> | Subject | Re: 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 (mpm@selenic.com) 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 application.
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 -- Peter Williams pwil3058@bigpond.net.au
"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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |