lkml.org 
[lkml]   [2006]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Rationale for RLIMIT_MEMLOCK?
    From
    Date
    `
    >
    > 1. What is the reason we're having special treatment
    > for the super-user here?

    it's quite common to allow root (or more specific, the right capability)
    to override rlimits. Many such security check behave that way so it's
    only "just" to treat this one like that as well.


    > 2. Why is it the opposite of what 2.6.8.1 and earlier did?

    the earlier behavior didn't really make sense, and gave cause to
    multimedia apps running as root only to be able to mlock etc etc. Now
    this can be dynamically controlled instead.


    > 4. Is the default hard limit of 32 kB initialized by the kernel or

    the kernel has a relatively low default. The reason is simple: allow too
    much mlock and the user can DoS the machine too easy. The kernel default
    should be safe, the admin / distro can very easily override anyway.

    You may ask: why is it not zero?
    It is very useful for many things to have a "small" mlock area. gpg, ssh
    and basically anything that works with keys and passwords. Small
    relative to the other resources such a process takes (eg kernel stacks
    etc).


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