* Matt Mackall ([EMAIL PROTECTED]) 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. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
