On 20/03/2021 22:13, Selva Nair wrote:
HI,
On Sat, Mar 20, 2021 at 4:57 PM Gert Doering <g...@greenie.muc.de
<mailto:g...@greenie.muc.de>> wrote:
Hi,
On Sat, Mar 20, 2021 at 12:20:45PM -0400, Selva Nair wrote:
> We should have probably made this not a FATAL error.
The rules could be twisted a bit ("if uid == 0 then not fatal"), but
generally speaking, we setrlimit() to avoid running into memory issues
later on - and if that fails, someone else is imposing restrictions
on us. So better fail right away than in malloc() later on.
With that patch we increased the capability requirements when using
--mlock. mlockall() only requires CAP_IPC_LOCK, it's the added
setrlimit() that needs CAP_SYS_RESOURCE.
So, someone who has carefully set the mlock limit to, say, 50MB based on
their needs, and using an existing systemd unit file will get an
unnecessary error exit.
Anyway let's document the new capability need for using mlock when
started with RLIMIT_MEMLOCK < 100MB. And update the included systemd
unit file.
As a short term solution, updating with CAP_SYS_RESOURCE may be
reasonable. But I think we need to look more into how we handle
capabilities inside OpenVPN, at least on Linux. For example, with the
new netlink interface in 2.5 (sitnl), OpenVPN should be able to be
*started* without root privileges as long as the user has CAP_NET_ADMIN.
But it may break other things expecting to run as root, which is why
we're threading carefully here for the moment.
But my main point is that we should actually have an improved pre-start
check where capabilities are evaluated and then warn or abort starting
up as early as possible. And once a capability is no longer needed, it
should be dropped, as ideally any program should run with as few
privileges as possible.
--
kind regards,
David Sommerseth
OpenVPN Inc
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
