Messages in this thread | | | Date | Tue, 24 Jan 2006 16:28:46 -0500 | From | Theodore Ts'o <> | Subject | Re: Rationale for RLIMIT_MEMLOCK? |
| |
On Tue, Jan 24, 2006 at 10:15:40AM +0100, Arjan van de Ven wrote: > On Tue, 2006-01-24 at 10:08 +0100, Joerg Schilling wrote: > > > the situation is messy; I can see some value in the hack Ted proposed to > > > just bump the rlimit automatically at an mlockall-done-by-root.. but to > > > be fair it's a hack :( > > > > As all other rlimits are honored even if you are root, it looks not orthogonal > > to disregard an existing RLIMIT_MEMLOCK rlimit if you are root. > > that's another solution; give root a higher rlimit by default for this. > It's also a bit messy, but a not-unreasonable default behavior.
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.
- Ted - 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/
| |