Am 07.03.21 um 19:44 schrieb Gert Doering: > Hi, > > On Sun, Mar 07, 2021 at 01:36:03PM -0500, Selva Nair wrote: >>> "I'm not sure", TBH. rlimit handling in unix is a bit of an unknown >>> territory for me. >>> >>> What I understand is that root can *increment* the rlimit at will, but >>> I'd assume that the rlimit value "in existance right now" (specifically, >>> the soft limit) applies to root processes as well. Sort of a voluntary >>> protection against processes running away. >> >> On modern linux kernels (since some 2.6.x..) RLIMIT_MEMLOCK applies only to >> unprivileged processes -- privileged processes allowed to lock "unlimited" >> amount of memory as documented in man mlock. We updated the man page based >> on that sometime ago. > > Indeed, "man mlock" says something about "privileged processes" on Linux > (it doesn't say that on FreeBSD). > >> We could also consider using setrlimit to increase the limit before >> dropping privileges. > > That's another possible angle... just up soft+hard to "something" > (how much would that be? :-) ) and log the fact. > > David, Arne, any opinion on this? Where do we want to go?
Looking at this feature from today's perspective, it feels like one of OpenVPN's boutique features. Was probably useful at some point but doesn't really make much sense today anymore. Esepcially with what is written in the manpage. Today you rather would use full disk encryption or disable swapping rather than to rely on OpenVPN's --mlock. That being said I am against your patch, I am just wondering if that is a feature we need to keep at all. Arne _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
