Messages in this thread | | | From | Joerg Schilling <> | Date | Wed, 25 Jan 2006 16:38:13 +0100 | Subject | Re: Rationale for RLIMIT_MEMLOCK? |
| |
Edgar Toernig <froese@gmx.de> wrote:
> Theodore Ts'o wrote: > > > > ... 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. > > What about exec? The memory locks are removed on exec but with that > hack the raised limit would stay. Looks like a security bug.
The RLIMIT_MEMLOCK feature itself may be a security bug implemented the way it currentlyy is.
For me it would make sense to be able to lock everything in core and then be able to tell the system that at most 1MB of additional memory may be locked.
In this case, there should be no general failure but the possibility to verify that the value is sufficient for usual cases.
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/
| |