• Linux setcap not working on non-symlink install

    From Daniel Clough@1:103/705 to GitLab issue in main/sbbs on Tue Jan 16 05:45:11 2024
    open https://gitlab.synchro.net/main/sbbs/-/issues/699

    I'm going to paste in the text from a message I posted on DoveNet regarding this:

    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.
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)