lkml.org 
[lkml]   [2006]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Rationale for RLIMIT_MEMLOCK?
    "Theodore Ts'o" <tytso@mit.edu> wrote:

    > I thought in the case we were talking about, the problem is that we
    > have a setuid program which calls mlockall() but then later drops its
    > privileges. So when it tries to allocate memories, RLIMIT_MEMLOCK
    > applies again, and so all future memory allocations would fail.
    >
    > What I proposed is a hack, but strictly speaking not necessary
    > according to the POSIX standards, but the problem is that a portable
    > program can't be expected to know that Linux has a RLIMIT_MEMLOCK
    > resource limit, such that a program which calls mlockall() and then
    > drops privileges will work under Solaris and fail under Linux. Hence
    > I why proposed a hack where mlockall() would adjust RLIMIT_MEMLOCK.
    > Yes, no question it's a hack and a special case; the question is
    > whether cure or the disease is worse.

    Maybe, I should give some hints...

    RLIMIT_MEMLOCK did first apear in BSD-4.4 around 1994.
    The iplementation is incomplete since then and partially disabled (size check
    for mmap() in the kernel) on FreeBSD as it has been 1994 on BSD-4.4

    FreeBSD currently uses a default value of RLIMIT_INFINITY for users.

    I could add this piece of code to the euid == 0 part of cdrecord:

    LOCAL void
    raise_memlock()
    {
    #ifdef RLIMIT_MEMLOCK
    struct rlimit rlim;

    rlim.rlim_cur = rlim.rlim_max = RLIM_INFINITY;

    if (setrlimit(RLIMIT_MEMLOCK, &rlim) < 0)
    errmsg("Warning: Cannot raise RLIMIT_MEMLOCK limits.");
    #endif /* RLIMIT_NOFILE */
    }

    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/

    \
     
     \ /
      Last update: 2006-01-25 16:37    [W:0.024 / U:32.280 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site