Messages in this thread | | | Subject | Re: Rationale for RLIMIT_MEMLOCK? | From | Arjan van de Ven <> | Date | Mon, 23 Jan 2006 12:05:12 +0100 |
| |
` > > 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/
| |