Re: 2.6.11-rc3-mm2

[Peter Williams]

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@xxxxxxxxxxx) 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@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/