Opened 7 years ago

Last modified 9 days ago

#293 assigned Bug / Defect

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

Reported by: agi Owned by:
Priority: minor Milestone: release 2.6
Component: Documentation Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Selva Nair

Description

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

Change History (5)

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 7 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 3 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?

comment:4 Changed 11 days ago by Gert Döring

This is also covered in #1059

comment:5 Changed 9 days ago by Gert Döring

Cc: Selva Nair added
Milestone: release 2.4release 2.6
Owner: Samuli Seppänen deleted
Version: OpenVPN 2.2.2 (Community Ed)OpenVPN git master branch (Community Ed)

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".

Note: See TracTickets for help on using tickets.