Using --mlock and --user makes openvpn "run out of memory"

[agi]

There's an open bug in Debian [1] since 2007, that seems to be quite
documented right now. To sum up, when you run openvpn with --mlock and
--user, the daemon will die with "out of memory", possibly due to
mlock(2):

BUGS
Since kernel 2.6.9, if a privileged process calls mlockall(MCL_FUTURE)
and later drops privileges (loses the CAP_IPC_LOCK capability by, for
example, setting its effective UID to a nonzero value), then
subsequent memory allocations (e.g., mmap(2), brk(2)) will fail if the
RLIMIT_MEMLOCK resource limit is encountered.

[1] ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406895

[JoshC]

I'm not sure the issue of preventing this failure case is something OpenVPN can fix. If the user running the OpenVPN process lacks OS-level permission to do something, OpenVPN will fail (as is the case with route changes, setting firewalls in connect scripts, and many other "possible" features.)

Perhaps looking at alternatives to mlockall() could limit the RAM requests through mlock(), but this is highly non-trivial as every bit of code that has security-sensitive data stored would then need to explicitly be allocated this way. This isn't likely to happen any time soon, and it's safe to say it's not a priority for any of the core dev team to attempt this.

The best way I see to resolve this issue is to document the requirement either run OpenVPN as root, or increase the OS limits for how much memory a program can allocate; this means increasing RLIMIT_MEMLOCK for the created process. This is how most other "root-requiring" options are handled today.

[Samuli Seppänen]

+1 for documenting this better.

[mvastola12]

I literally just ran into this issue (which is now over a decade old) on the latest OpenVPN package for the Ubuntu release.

I understand preventing this issue entirely may be beyond OpenVPN's control, but is there any way at least a warning could added at startup in the presence of this configuration combination?

[Gert Döring]

This is also covered in #1059

[Gert Döring]

We have added documentation in #1059

commit 5b815eb449314a43e2b73325948edea8a4cfb215 (master)
commit be68b361a9c95218c671ee86d25a29019bab7239 (release/2.5)
Author: Selva Nair
Date: Wed Sep 9 18:15:29 2020 -0400

Add a remark on dropping privileges when --mlock is used

detecting this situation at runtime is possible (getrlimit()) but non-trivial - I am leaving this ticket open, with "milestone 2.6", so someone who wants to delve into this can see "here is work to do".

[Gert Döring]

We have more activity including a patch in #1390 - that is "documentation update in 2.5, and actual setrlimit() activity in 2.6".

So this one can be closed.