Failed to drop privileges: DropPrivileges("Failed to permanently drop privileges")

[dylan-deep-stack]

** when i run root ./boringtun -f wg0 Failed to drop privileges: DropPrivileges("Failed to permanently drop privileges")

It hava a error message **

[dylan-deep-stack]

This is fixed when i running command " boringtun wg1 --disable-drop-privileges root"

boringtun wg1 --disable-drop-privileges root BoringTun started successfully

[ian-otto]

What Operating System and what version are you running?

[wmiller848]

I'm attempting to run BoringTun in a docker container and run into this even with the --privileged flag providing the container with full privileged access and running as the root user in the container.

sudo boringtun wg0 -f
Poll error Interrupted system call
Poll error Interrupted system call
Poll error Interrupted system call
Poll error Interrupted system call
Poll error Interrupted system call
Poll error Interrupted system call
Failed to drop privileges: DropPrivileges("Failed to permanently drop privileges")

vs

sudo boringtun wg0 -f --disable-drop-privileges root

boringtun --version
boringtun 0.3.0

Compiled from 700f20bf2a060953911c998c02dea821a43c09ca on Alpine

cat /etc/alpine-release
3.12_alpha20191219

uname -mrvo
4.19.88 #1 SMP Tue Feb 4 22:25:03 PST 2020 x86_64 Linux

Any suggestions would be helpful thanks!

[Menci]

The code in https://github.com/cloudflare/boringtun/blob/34cc88c1d6599cc88cf0c336693ab51a00e962b1/src/device/drop_privileges.rs assumes user runs boringtun with sudo under a non-root user. It gets the original username and uid/gid and then setuid/getgid to it, finally it checks it can't set them back to root. So invoke boringtun in a root login shell will result in this error.

I don't know WHY they can make such a assumption.

A fix could be adding a check in drop_privileges(). When the getlogin function returns root, don't drop privileges.

[mikma]

@wmiller848

on Alpine

Apparently getlogin on musl (used by Alpine) returns root when you use sudo, which means boringtun can't drop privileges.

Maybe SUDO_UID and SUDO_GID can be used if they are available?

[twittner]

Musl's getlogin returns getenv("LOGNAME"). Dropping privileges should work if LOGNAME is set appropriately, e.g.

$ whoami
alpine
$ sudo boringtun wg0
BoringTun failed to start
$ sudo env LOGNAME=alpine boringtun wg0
BoringTun started successfully

[parke]

Musl's getlogin returns getenv("LOGNAME"). Dropping privileges should work if LOGNAME is set appropriately, e.g.

$ whoami
alpine
$ sudo boringtun wg0
BoringTun failed to start
$ sudo env LOGNAME=alpine boringtun wg0
BoringTun started successfully

If you don't want to use sudo, then another similar workaround (on musl-based systems) is to run boringtun-cli as root, but with LOGNAME set to the user you want boringtun-cli to become. For example:

# whoami
root
# LOGNAME=someuser ./boringtun-cli wg0
BoringTun started successfully