Messages in this thread | | | From | Joerg Schilling <> | Date | Mon, 23 Jan 2006 20:38:52 +0100 | Subject | Re: Rationale for RLIMIT_MEMLOCK? |
| |
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.
Jörg
-- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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/
| |