lkml.org 
[lkml]   [2006]   [Jan]   [24]   [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, Theodore Ts'o wrote:

    > On Mon, Jan 23, 2006 at 07:55:49PM +0100, Matthias Andree wrote:
    > > 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.
    >
    > Maybe mlockall(MLC_FUTURE) when run with privileges should
    > automatically adjust the RLIMIT_MEMLOCK resource limit?

    Adding special cases to no end.
    Is this really sensible?

    How about leaving RLIMIT_MEMLOCK alone (and at RLIM_INFINITY) for root
    processes altogether? At least that wouldn't add a new special case but
    just change the existing one to remove an inconsistency, and the effect
    will be the same, only that it is inherited across seteuid().

    I doubt that the kernel is the right place to implement policies that
    belong into user space. As long as the kernel is meant to be universal,
    any default will collide with an application's requirement sooner or
    later.

    --
    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-24 12:08    [W:2.245 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site