Messages in this thread | | | Date | Fri, 3 Feb 2006 21:49:20 +0100 (MET) | From | "Michael Kerrisk" <> | Subject | Re: Rationale for RLIMIT_MEMLOCK? |
| |
> > Matthias Andree <matthias.andree@gmx.de> wrote:
[...]
> The complete story is, condensed, and with return values, for a > setuid-root application: > > geteuid() == 0; > mlockall(MLC_CURRENT|MLC_FUTURE) == (success); > seteuid(500) == (success); > valloc(64512 + pagesize) == NULL (failure);
[...]
A late follow-up to this thread. I've added the following text to the mlockall() manual pag under BUGS:
Since kernel 2.6.9, if a privileged process calls mlockall(MCL_FUTURE) and later drops privileges (CAP_IPC_LOCK), then subsequent memory allocations (e.g., mmap(2), sbrk(2)) will fail if the RLIMIT_MEMLOCK resource limit is encountered.
The change will be in man-pages 2.23.
Cheers,
Michael
-- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance? Grab the latest tarball at ftp://ftp.win.tue.nl/pub/linux-local/manpages/, read the HOWTOHELP file and grep the source files for 'FIXME'. - 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/
| |