Messages in this thread | | | Date | Mon, 23 Jan 2006 19:55:49 +0100 | From | Matthias Andree <> | Subject | Re: Rationale for RLIMIT_MEMLOCK? |
| |
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.
The function in question appears to be valloc() with glibc 2.3.5.
In this light, mlockall(MCL_FUTURE) is pretty useless, since there is no way to undo MCL_FUTURE without unlocking all pages at the same time. Particularly so for setuid apps...
I'm asking the Bcc'd gentleman to reconsider mlockall() and perhaps use explicit mlock() instead.
-- Matthias Andree - 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/
| |