Messages in this thread | | | From | Joerg Schilling <> | Date | Wed, 25 Jan 2006 16:33:06 +0100 | Subject | Re: 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/
| |