[lkml]   [2005]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] [request for inclusion] Realtime LSM
    > On Sat, Jan 08, 2005 at 12:12:59AM -0600, Jack O'Quin wrote:
    >> I find it hard to understand why some of you think PAM is an adequate
    >> solution.

    Matt Mackall <> writes:
    > The best we can do _here_ is present something that userspace can use
    > sensibly. We can't make userspace actually use it that way though.

    "O'Quin's law" states that "every system reflects the structure of the
    organization creating it". (Probably not original, I "discovered"
    this about 25 years ago, while doing OS development at IBM.) Compared
    to most other operating systems, GNU/Linux has a much larger
    organizational gap between kernel development and the rest of the OS.
    Like anything else, this is both a strength and a weakness.

    > Rlimits are neither UID/GID or PAM-specific. They fit well within
    > the general model of UNIX security, extending an existing mechanism
    > rather than adding a completely new one. That PAM happens to be the
    > way rlimits are usually administered may be unfortunate, yes, but it
    > doesn't mean that rlimits is the wrong way.

    This whole RLIMITS_MEMLOCK situation with PAM is a good example of how
    that disconnect causes systemic troubles. AFAICT, fixing the
    longstanding bug in mlock() introduced a Denial of Service bug in
    Debian (and perhaps other distributions) when running 2.6.10.

    Clearly, this is not a kernel bug. In fact, the kernel was broken
    before. But, it is an excellent example of how depending on a
    Byzantine mechanism like PAM *harms* system security. The Debian
    developers are very careful about things like this. If they can't get
    the default install right, something is badly amiss, damaging
    complexity in the overall system. The kernel is not solely
    responsible for that, but ignoring its contribution would be a

    >> Running `nice --20' is still significantly worse than SCHED_FIFO, but
    >> not the unmitigated disaster shown in the middle column. But, this
    >> improved performance is still not adequate for audio work. The worst
    >> delay was absurdly long (~1/2 sec).
    > Let's work on that. It'd be _far_ better to have unprivileged near-RT
    > capability everywhere without potential scheduling DoS.

    "Near-RT" is about the most useless concept I've heard of in a long
    time. It sounds like the answer to a question nobody asked. ;-)

    Linux can and should develop a better unprivileged realtime scheduling
    algorithm. But, this is not an "escape hatch" to avoid confronting
    mainline 2.6 security problems. We still have 2005 problems to solve.
    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:09    [W:0.022 / U:21.524 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site