[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 Tue, 2005-01-11 at 10:28 -0600, Jack O'Quin wrote:
    > Paul Davis <> writes:
    > >>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.
    > PAM is how most GNU/Linux systems manage rlimits. It is very UID/GID
    > oriented. So from the sysadmin perspective, claiming that rlimits is
    > "better" or "easier to manage" than "GID hacks" is bogus.

    Why do you have such a problem with a rlimit base approach?
    IMHO it's not a hack like realtime LSM, usable for other things beside
    pro audio (see "scheduling priorities with rlimit" thread), securer and
    more user friendly.

    With realtime LSM a user in the realtime group can change the nice
    values and RT priorities of other users processes, incl. owned by root
    and kernel threads. This has to be fixed. I think this means a rewrite
    (not using CAP_SYS_NICE).

    It can't be used with distro kernels which have common-caps complied in,
    eg. fedora.

    IMHO for a possible mainline inclusion the mlock part have to taken away
    because RLIMIT_MLOCK is a better solution. A pro audio user have to deal
    with rlimits for mlock and realtime LSM for the RT priority part.
    Doing both with rlimits is more user friendly. Most of them have only to
    put something like this in limits.conf:

    me hard memlock 500000
    me soft memlock 500000
    me hard realtime 60
    me soft realtime 60

    And with rlimits you can drop privileges on process basis. Just set the
    hard RLIMIT_RT to 0 (ulimit). You can't do this with realtime LSM.

    With realtime rlimit you can even think about to give users realtime
    prios on a multi user machine. Limit the RT prio for users to 10 and
    have a rt-watchdog process with a higher priority which kills runaway
    user RT processes.
    With realtime LSM you can't limit the RT prio. It's all or nothing.

    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.040 / U:4.684 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site