lkml.org 
[lkml]   [2006]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2006-01-23 19:58    [W:2.545 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site