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

From: Chris Wright
Date: Tue Mar 08 2005 - 00:01:30 EST

* Matt Mackall (mpm@xxxxxxxxxxx) wrote:
> On Tue, Mar 08, 2005 at 04:32:50AM +0000, Christoph Hellwig wrote:
> > On Mon, Mar 07, 2005 at 08:28:21PM -0800, Andrew Morton wrote:
> > > > please describe this "very simple and very real-world problem" in simple
> > > > terms. Lets make sure "problem" and "solution" didnt become detached.
> > > >
> > >
> > > Well others can do that better than I but I'd describe it as
> > >
> > > - Audio apps need to meet their realtime requirements
> Add video, data acquisition, motion control, CD burning, etc..
> > > - The way to implement that is to give them !SCHED_OTHER and mlockall
> > > capabilities.
> > >
> > > - But they don't want to run as root.
> >
> > Which all fits very nicely with MEMLOCK rlimit and a tiny wrapper
> > that sets !SCHED_OTHER and execs the audio app..
> This is somewhat complicated by the fact that the existing apps are
> already running and instead need promotion. Then we run into problems
> lie set_rlimit doesn't want to work on other processes and issues with
> sched_setparam on other threads, etc.
> Part of me wants to say, well you designed it wrong. You should have
> planned a setuid launcher for the rt threads. But at the same time,
> the rlimits thing seems like a reasonably clean way to give RT access
> to users, and still allows for protect watchdog processes..
> > and as I mentioned a few times if we really want to go for a magic
> > uid/gid-based approach we should at least have one that's useable for
> > all capabilities so it can replace the oracle hack aswell. But the
> > proponents of the patch weren't iterested to invest the tiniest bit
> > of work over what they submited.
> Does the mlock rlimit not already address the Oracle problem?

It does, that's effectively dead code as far as I'm concerned. The mlock
bit just came in a bit later. I had a patch around here to rip it out,
this should be a good time to dust that off.

Linux Security Modules
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at