text: "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.4FreeBSD 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 */ }