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

From: Matt Mackall
Date: Mon Mar 07 2005 - 23:52:09 EST


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?

--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/