Re: [PATCH] [request for inclusion] Realtime LSM

Chris Wright
2005-01-11T21:46:25Z

* Matt Mackall (mpm@selenic.com) wrote:
> On Tue, Jan 11, 2005 at 12:47:07PM -0800, Chris Wright wrote:
> > Guys, could we please bring this back to a useful discussion. None of
> > you have commented on whether the rlimits for priority are useful. As I
> > said before, I've no real problem with the module as it stands since it's
> > tiny, quite contained, and does something people need. But I agree it'd
> > be better to find something that's workable as long term solution.
>
> I almost like it. I don't like that it exposes the internal scheduler
> priorities directly (-tiny in fact has options to change these!). So
> perhaps some thought could be given to either stratifying it a bit
> more (>2000 for SCHED_FIFO, >1000 for SCHED_RR, then SCHED_OTHER) or
> separate limits for the different scheduling disciplines.

Yeah, I don't like that either (thought I mentioned it in earliest
patch). I thought about the method you mentioned, but didn't like it
much better. I also suggested using 0 == default, 1 == can nice down,
2 == can set RT prio. Utz suggests just splitting nice limit from rt
limit.

> But I'm also still not convinced this policy can't be most flexibly
> handled by a setuid helper together with the mlock rlimit.

Wait, why can't it be done with (to date fictitious) pam_prio, which
simply calls sched_setscheduler? It's already privileged while it's
doing these things...

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net