use unix socket for bitmask-helper local api

bitmask-vpn installs a daemon called bitmask-helper which exposes a http api to handle firewall up/down and openvpn connect/disconnect (only in macos)

this helper was listening on localhost, since it is meant to be only accessible to local processes we'v changed it to listen on a unix domain socket

added 9 commits

• cb77a6a9...f2f1e40e - 8 commits from branch main
• 4975daa3 - use unix socket for bitmask-helper local api

Compare with previous version

added 3 commits

• 4975daa3...c68cfe08 - 2 commits from branch main
• ec2f205a - use unix socket for bitmask-helper local api

Compare with previous version

@mcnair could you please give this a try on macOS, MR artifact can be downloaded from: https://0xacab.org/leap/bitmask-vpn/-/jobs/653041/artifacts/browse/build/installer/

added 1 commit

• cf43de2a - helper: use unix socket for local api

Compare with previous version

added 6 commits

• cf43de2a...1c5678ce - 5 commits from branch main
• 95d1bea5 - helper: use unix socket for local api

Compare with previous version

resolved all threads

I think at this point we need to return as we call serveHTTP(unixListener) and unixListener can be nil here.

there's one advantage of not calling return here, it is that when this calls serveHTTP and that fails, we'll get a non-success exit code/fatal error

I tested it: In serveHTTP when calling server.Serve(nil), it panics.

yes not very elegant, but it'll panic and return a non zero exit code, whereas if we return the exit code will be 0 which means the service won't be restarted by launchd overall error handling improvements are needed! maybe create an issue and we can include it in a milestone during planning

What confuses me (but I think i get it):

• bitmask-helper is executed on Windows and Mac automatically (cmd/bitmask-helper/main.go calls helper.StartHelper())
• StartHelper() in defined in pkg/helper/helper.go and executed for every OS. It calls runServer()
• runServer() is implemented for each OS seperatedly (windows.go listener_unix.go)

Then the docs need to be updated (that we now also support unix domain socket):

in pkg/helper/helper.go:

// In Windows, this helper will run on the first available port after the standard one (7171). // In other systems, the 7171 port is hardcoded.

// startHelper is the main entrypoint. It can react to cli args (used to install or manage the service in windows), and // eventually will start the http server.

It's a bit confusing that StartHelper calls initializeService(port) and runServer(socketUid, socketGid) (seems like it runs both - port listener and socket listener). But I think we don't want to rewrite that part...

A) When I terminate bitmask-helper (with ctrl-c), it does not delete the socket /tmp/bitmask-helper.sock
B) Maybe check that it is run as root?:

2024-10-15T09:37:41+02:00 FTL unable to change owner of socket file error="chown /tmp/bitmask-helper.sock: operation not permitted"

C) Isn't it easier to just run it as the user instead of running it as root and doing the chmod?

D) Maybe tell useres how to test the unix socket (version is empty here for me...?):

pea@peabox:bitmask-vpn curl --unix-socket /tmp/bitmask-helper.sock http://bitmask/version       
/

added 1h of time spent at 2024-10-14

It's a bit confusing that StartHelper calls initializeService(port) and runServer(socketUid, socketGid) (seems like it runs both - port listener and socket listener). But I think we don't want to rewrite that part...

it only creates a unix socket now, did you check if the port was actually occupied when running?

A) When I terminate bitmask-helper (with ctrl-c), it does not delete the socket /tmp/bitmask-helper.sock
B) Maybe check that it is run as root?:

the deleting of the socket happens at startup, it is run as an OS service (on macos this is launchd) so the root check could be there, but since we control the launchd service definition this is not necessary currently

C) Isn't it easier to just run it as the user instead of running it as root and doing the chmod?

bitmask-helper needs to run as root since it needs to start/stop firewall and start the openvpn process which creates the tun device, but we don't want to run the whole bitmask-vpn app as root that's why, we interact with it using the http API and run the relatively small codebase bitmask-helper as root

D) Maybe tell useres how to test the unix socket (version is empty here for me...?):

its not meant to be used by users directly, its a helper program for only bitmask-vpn desktop app, look at the make build_helper target for the version things

added 1 commit

• 2e669b8f - helper: use unix socket for local api

Compare with previous version

it only creates a unix socket now, did you check if the port was actually occupied when running?

It works like expected. But when I read the code it seems like it does both (something with the port and someting with the unix socket - initializeService(port) and later runServer(socketUid, socketGid))

its not meant to be used by users directly, its a helper program for only ...

Yea, I just meant for debugging purposes

added 2 commits

• 7e176df8 - 1 commit from branch main
• d98efd23 - helper: use unix socket for local api

Compare with previous version

enabled an automatic merge when all merge checks for d98efd23 pass

merged