Opened 7 years ago

Last modified 2 years ago

#293 assigned Bug / Defect

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

Reported by: agi Owned by: Samuli Seppänen
Priority: minor Milestone: release 2.4
Component: Documentation Version: OpenVPN 2.2.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


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

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.


Change History (3)

comment:1 Changed 7 years ago by JoshC

Priority: majorminor

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.

comment:2 Changed 6 years ago by Samuli Seppänen

Component: Generic / unclassifiedDocumentation
Milestone: release 2.4
Owner: set to Samuli Seppänen
Status: newassigned

+1 for documenting this better.

comment:3 Changed 2 years ago by 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?

Note: See TracTickets for help on using tickets.