feature-requesthelp wantedserver
Description
Murmur on Linux is typically built with capabilities support. This makes it impossible to set CAP_NET_BIND_SERVICE, because Murmur will remove it during startup.
Perhaps Murmur should just have CAP_NET_BIND_SERVICE on by default on Linux? Alternatively, a config option that adds it to Murmur capability set would be very welcome.
The use-case would be to have an escape hatch where Murmur can work on restrictive networks that only allow port 80/443.
IRC log:
11:16:01 <archer121_> hi, I installed murmer on a AWS instance. And then I changed to port 80. Then i restarted mumber server, but then it's not listening on 80
11:16:11 <archer121_> how do I know what went wrong?
11:16:47 <archer121_> On the server, I do a "telnet localhost 443" and it says connection refused
11:17:36 <archer121_> s/443/80
11:18:34 <archer121_> I fall back to 64738, and it's working
11:21:53 <archer121_> maybe murmer doesn't have permission to listen on 80, and fails? How to fix this?
11:31:48 <@mkrautz> archer121_: Murmur drops root privileges quite early, so Murmur won't be able to listen on privileged ports (< 1024)
11:32:26 <@mkrautz> archer121_: we do however use linux capabilities for some other things, so it's possible we could add the CAP_NET_BIND_SERVICE capability to murmur, to be able to listen on privileged ports
11:33:05 <archer121_> Is there a quick fix to this?
11:33:15 <@mkrautz> archer121_: typically, people will recommend that you set the capability on the binary: setcap cap_net_bind_service=+ep /usr/sbin/murmurd
11:33:30 <@mkrautz> but since Murmur uses capabilities internally, I don't know if it will "stick"...
11:33:44 <@mkrautz> ^ note you need to run the command as root.
11:35:17 <archer121_> let me check
11:36:32 <archer121_> nah. Doesn't work
11:37:49 <@mkrautz> why do you want to use port 80 anyway? murmur uses both tcp and udp, so if it's an escape hatch for stupid network policies, then you probably will suffer, in that you probably won't be able to use the udp voice transport anyway?
11:38:30 <ham5> couldent you do something with firewall/nat on 80 and reroute to 64738
11:38:40 <archer121_> ohh, can't I udp over port 80?
11:39:28 <@mkrautz> archer121_: well, if you're trying to make it "work" over very restrictive firewalls that only allow port 80/443 traffic, they'll probably only allow TCP traffic
11:39:50 <@mkrautz> Mumble WILL work over TCP, but a little worse, due to TCP overhead
11:40:15 <archer121_> I see
11:40:28 <@mkrautz> archer121_, ham5: yes, you could do it at the network layer... but I can't help with that :-)
11:40:55 <archer121_> I guess, the only option that I can see is to use a ssh tunnel (yuck?)
11:41:44 <@mkrautz> however, that requires reciting satanic incantations, which I am not comfortable with
11:42:11 <@mkrautz> archer121_: you could probably set up some iptables rules to make both port 80 and 64738 work
11:42:23 <archer121_> umm
11:42:28 <archer121_> I'll read on that
11:42:36 <@mkrautz> archer121_: what's the use case here? I still don't know why you want port 80, I'm just guessing
11:43:18 <archer121_> same, college firewall allows only 80, 443