Messages in this thread | | | Subject | Re: Rationale for RLIMIT_MEMLOCK? | From | Lee Revell <> | Date | Mon, 23 Jan 2006 15:30:54 -0500 |
| |
On Mon, 2006-01-23 at 20:38 +0100, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > On Mon, 23 Jan 2006, Arjan van de Ven wrote: > > > > > hmm... curious that mlockall() succeeds with only a 32kb rlimit.... > > > > It's quite obvious with the seteuid() shuffling behind the scenes of the > > app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0. > > > > Clearly the application should do both with the same privilege or raise > > the RLIMIT_MEMLOCK while running with privileges. > > > > The question that's open is one for the libc guys: malloc(), valloc() > > and others seem to use mmap() on some occasions (for some allocation > > sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and > > if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc > > is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and > > then drops privileges. > > If the behavior described by Matthias is true for current Linuc kernels, > then there is a clean bug that needs fixing. > > If the Linux kernel is not willing to accept the contract by > mlockall(MLC_FUTURE), then it should now accept the call at all. > > In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later > ignores this contract. This bug should be fixed.
Joerg,
You will be happy to know that in future Linux distros, cdrecord will not require setuid to mlock() and get SCHED_FIFO - both are now controlled by rlimits, so if the distro ships with a sane PAM/group configuration, all you will need to do is add cdrecord users to the "realtime" or "cdrecord" or "audio" group.
This will take a while to make it into distros as it requires changes to PAM and glibc in addition to the kernel.
Lee
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |