lkml.org 
[lkml]   [2005]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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 (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/

    \
     
     \ /
      Last update: 2005-03-22 14:10    [W:0.552 / U:0.204 seconds]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean