Hi DM,

I've been off-and-on fighting with using 'setcap' to allow binding to
low ports as a non-root user, and today found (I think) what might be
causing my difficulties.

I've been doing my updates with an automated script, and the setcap
option on the make line didn't seem to work. So, I was trying to use it
in the update script as a command (sudo setcap ...<blah>). That didn't
work either, and I think it's because there are weird/complicated things
with 'setuid' and 'inherited' permissions type things in a bash script.
With both of those issues not working, I just manually did the setcap
command after the build was complete, and that works as expected.

So today I once again used the command on the make line, thus:

cd /sbbs/repo/src/sbbs3; make RELEASE=1 setcap install

That *appears* to work, as the relevant make output is this:

Linking gcc.linux.x64.exe.release/umonitor
make[1]: Leaving directory '/sbbs/repo/src/sbbs3/umonitor'
sudo `whereis -b setcap | cut -d" " -f2` 'cap_net_bind_service=+ep' gcc.linux.x64.exe.release/sbbs
install gcc.linux.x64.exe.release/* /sbbs/exec
install gcc.linux.x64.lib.release/* /sbbs/exec
install */gcc.linux.x64.exe.release/* /sbbs/exec

(side note: it doesn't prompt me for user password because I have my
user allowed to run all sudo commands without a password).

The problem is that it.... still doesn't work, 'sbbs' fails to bind to a
low port number. So I started looking closer. In a Linux terminal
window, my files appear in different colors depending on file
extensions, when using the 'ls' command. The executable files in
/sbbs/exec are green, for example. The 'sbbs' executable is green after running the build. If I manually use setcap to give it binding
capabilities, it now shows as black text on a red background, which I'm
sure means it is now considered some kind of "special" file.
However.... the 'sbbs' executable in /sbbs/repo/src/sbbs3/gcc.linux.x64.exe.release/ is.... RED, even when
the 'sbbs' executable in /sbbs/exec is green (not capable). What's
happening is that the install commands there above that copy the newly compiled executables to /sbbs/exec remove the special capabilities.

This problem isn't noticed by those that use 'symlinks' on their make
line, only when a person uses 'install', because that copies the file somewhere else, which apparently breaks the capabilites that it's been
given.

That isn't a Synchronet problem, and I'm guessing not a compiler problem either, but it is an unexpected behavior.

Do you know of a way to improve this? I understand it may be a systemic
Linux problem rather than SBBS, and if so, I'll continue to manually run
the setcap command. The aggravating part is that it can't be automated
in a bash script either, to my knowledge.

Thanks for listening to this rather long explanation. :-)



... Internal Error: The system has been taken over by sheep at line 19960
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Linux setcap question
By: Gamgee to Digital Man on Mon Jan 15 2024 04:44 pm

I've been doing my updates with an automated script, and the setcap option on the make line didn't seem to work. So, I was trying to use it in the update script as a command (sudo setcap ...<blah>). That didn't work either, and I think it's because there are weird/complicated things with

cd /sbbs/repo/src/sbbs3; make RELEASE=1 setcap install

This problem isn't noticed by those that use 'symlinks' on their make line, only when a person uses 'install', because that copies the file somewhere else, which apparently breaks the capabilites that it's been given.

I know I'm not DM, but I also have a Bash script I wrote to update and rebuild and do th setcap thing to make them executable (I also don't use symlinks). I'm using the same make command:

make RELEASE=1 setcap install

Also, right after that, I see that I have this (note that within the if/fi, ther eare 2 commands, and this is line-wrapping):

if [ $? -eq 0 ]; then
sudo setcap cap_net_bind_service+epi ~/BBS/sbbs/repo/src/sbbs3/gcc.linux.x64.exe.release/sbbs
sudo setcap cap_net_bind_service+epi ~/BBS/sbbs/exec/sbbs
fi

That seems to work for me.

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Nightfox wrote to Gamgee <=-

Re: Linux setcap question
By: Gamgee to Digital Man on Mon Jan 15 2024 04:44 pm

I've been doing my updates with an automated script, and the setcap option on the make line didn't seem to work. So, I was trying to use it in the update script as a command (sudo setcap ...<blah>). That didn't work either, and I think it's because there are weird/complicated things with

cd /sbbs/repo/src/sbbs3; make RELEASE=1 setcap install

This problem isn't noticed by those that use 'symlinks' on their make line, only when a person uses 'install', because that copies the file somewhere else, which apparently breaks the capabilites that it's been given.

I know I'm not DM, but I also have a Bash script I wrote to
update and rebuild and do th setcap thing to make them executable
(I also don't use symlinks). I'm using the same make command:

make RELEASE=1 setcap install

Also, right after that, I see that I have this (note that within
the if/fi, ther eare 2 commands, and this is line-wrapping):

if [ $? -eq 0 ]; then
sudo setcap cap_net_bind_service+epi ~/BBS/sbbs/repo/src/sbbs3/gcc.linux.x64.exe.release/sbbs
sudo setcap cap_net_bind_service+epi ~/BBS/sbbs/exec/sbbs
fi

That seems to work for me.

Yep, that's basically exactly what I'm doing, although there's no real
point in doing it twice there... You don't really need the capabilities on
the sbbs executable that's in the repo path, if you're not using symlinks.

Also, if you're going to do that in the bash script, there's not really
any point in having the 'setcap' command on the make line.

My problem is that my bash script doesn't perform the setting of
capabilities as expected. It doesn't seem to *fail*, but just doesn't do anything to the executable. I just noticed that I don't have the "i"
included (as in your +epi), which has something to do with "inheretid" properties. I guess I'll try adding that and see if it helps. I'm using Slackware, but don't think that should matter either.

Thanks for the input!



... Internal Error: The system has been taken over by sheep at line 19960
=== MultiMail/Linux v0.52
--- SBBSecho 3.20-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

Re: Linux setcap question
By: Gamgee to Digital Man on Mon Jan 15 2024 04:44 pm

Hi DM,

I've been off-and-on fighting with using 'setcap' to allow binding to
low ports as a non-root user, and today found (I think) what might be causing my difficulties.

I've been doing my updates with an automated script, and the setcap
option on the make line didn't seem to work. So, I was trying to use it
in the update script as a command (sudo setcap ...<blah>). That didn't
work either, and I think it's because there are weird/complicated things with 'setuid' and 'inherited' permissions type things in a bash script.
With both of those issues not working, I just manually did the setcap command after the build was complete, and that works as expected.

So today I once again used the command on the make line, thus:

cd /sbbs/repo/src/sbbs3; make RELEASE=1 setcap install

That *appears* to work, as the relevant make output is this:

Linking gcc.linux.x64.exe.release/umonitor
make[1]: Leaving directory '/sbbs/repo/src/sbbs3/umonitor'
sudo `whereis -b setcap | cut -d" " -f2` 'cap_net_bind_service=+ep' gcc.linux.x64.exe.release/sbbs
install gcc.linux.x64.exe.release/* /sbbs/exec
install gcc.linux.x64.lib.release/* /sbbs/exec
install */gcc.linux.x64.exe.release/* /sbbs/exec

The problem is that it.... still doesn't work, 'sbbs' fails to bind to a
low port number. So I started looking closer. In a Linux terminal
window, my files appear in different colors depending on file
extensions, when using the 'ls' command. The executable files in
/sbbs/exec are green, for example. The 'sbbs' executable is green after running the build. If I manually use setcap to give it binding capabilities, it now shows as black text on a red background, which I'm
sure means it is now considered some kind of "special" file.
However.... the 'sbbs' executable in /sbbs/repo/src/sbbs3/gcc.linux.x64.exe.release/ is.... RED, even when
the 'sbbs' executable in /sbbs/exec is green (not capable). What's happening is that the install commands there above that copy the newly compiled executables to /sbbs/exec remove the special capabilities.

This problem isn't noticed by those that use 'symlinks' on their make
line, only when a person uses 'install', because that copies the file somewhere else, which apparently breaks the capabilites that it's been given.

This is all a good data point and could possibly be addressed in the src/sbbs3/GNUmakefile (or child .mk files), but the real/best solution is to not use capabilities but rather the AmbientCapabilities=CAP_NET_BIND_SERVICE line in the [Service] section of your systemd unit file (e.g. sbbs.service).

Creating an issue in gitlab.synchro.net would help to remind us/me to address it in the wiki or the makefiles.
--
digital man (rob)

Synchronet/BBS Terminology Definition #40:
HTTPS = Secure HTTP (authenticated and encrypted HTTP over TLS)
Norco, CA WX: 58.4øF, 68.0% humidity, 2 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

I've been off-and-on fighting with using 'setcap' to allow binding to
low ports as a non-root user, and today found (I think) what might be causing my difficulties.

I've been doing my updates with an automated script, and the setcap
option on the make line didn't seem to work. So, I was trying to use it
in the update script as a command (sudo setcap ...<blah>). That didn't
work either, and I think it's because there are weird/complicated things with 'setuid' and 'inherited' permissions type things in a bash script.
With both of those issues not working, I just manually did the setcap command after the build was complete, and that works as expected.

So today I once again used the command on the make line, thus:

cd /sbbs/repo/src/sbbs3; make RELEASE=1 setcap install

That *appears* to work, as the relevant make output is this:

Linking gcc.linux.x64.exe.release/umonitor
make[1]: Leaving directory '/sbbs/repo/src/sbbs3/umonitor'
sudo `whereis -b setcap | cut -d" " -f2` 'cap_net_bind_service=+ep' gcc.linux.x64.exe.release/sbbs
install gcc.linux.x64.exe.release/* /sbbs/exec
install gcc.linux.x64.lib.release/* /sbbs/exec
install */gcc.linux.x64.exe.release/* /sbbs/exec

The problem is that it.... still doesn't work, 'sbbs' fails to bind to a
low port number. So I started looking closer. In a Linux terminal
window, my files appear in different colors depending on file
extensions, when using the 'ls' command. The executable files in
/sbbs/exec are green, for example. The 'sbbs' executable is green after running the build. If I manually use setcap to give it binding capabilities, it now shows as black text on a red background, which I'm
sure means it is now considered some kind of "special" file.
However.... the 'sbbs' executable in /sbbs/repo/src/sbbs3/gcc.linux.x64.exe.release/ is.... RED, even when
the 'sbbs' executable in /sbbs/exec is green (not capable). What's happening is that the install commands there above that copy the newly compiled executables to /sbbs/exec remove the special capabilities.

This problem isn't noticed by those that use 'symlinks' on their make
line, only when a person uses 'install', because that copies the file somewhere else, which apparently breaks the capabilites that it's been given.

This is all a good data point and could possibly be addressed in
the src/sbbs3/GNUmakefile (or child .mk files), but the real/best

Okay, that would be excellent.

solution is to not use capabilities but rather the AmbientCapabilities=CAP_NET_BIND_SERVICE line in the [Service]
section of your systemd unit file (e.g. sbbs.service).

Can't do that here, as I don't have any of that stuff (Slackware doesn't
use systemd), and I like it that way. ;-)

Creating an issue in gitlab.synchro.net would help to remind
us/me to address it in the wiki or the makefiles.

All right, I'll do that. Thanks DigitalMan.



... If it weren't for Edison we'd be using computers by candlelight
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)