Originally posted by fr24-pad
View Post
All of these additional activities were added after we switched from running fr24feed as root to a non-privileged user (fr24).
This was long-awaited and asked by many feeders and you probably wouldn't argue that this is a good change to make.
However, this came with a variety of unexpected issues due to different user setups, operating systems, broken system packages which were almost impossible to anticipate and test on our test stand. Some of them we are still unable to reproduce.
To your suggestions,
1. ping suid bit. On many OS it is set by default and even e.g. on old Jessie versions ping completely fails without suid bit: https://www.raspberrypi.org/forums/v...c.php?t=129242
There is an option to use setcap instead of suid, but that is risky as requires additional OS support for it. So we've fixed it this way to remediate the problem ASAP and plan to test setcap more thoroughly before introducing it for everyone.
2. I agree that it might be more clear to check first (from a clear-code perspective), but useradd will fail if a user exists, so I don't completely buy the argument.
3. Yes, we need to allow both fr24 and pi users to write to this file (to allow signup). Some systems do not have 'pi' user. Could we do better, e.g. creating a group instead? Sure. But for now it just complicates things and though I agree with general security practices, it feels like overengineering things for now. We will definitely come back to this later.
4. That seems to be correct by checking quickly, it was missed because of two different directories for this config and users reported that the latter not working. Needs more testing and verification, though I can't see it being critical to be honest.
5. Actions performed on fr24feed.service start:
- install dump1090 (if needed). As I mentioned few posts earlier, of course there is a way to package this to our repository and install via apt-get directly. No doubt this is a nice way. Unfortunately dump1090 is not our software and there are multiple activities needed to support the repository. We will definitely look into this further, but for now I don't see how this would help to solve anything.
- unregister dvb-related kernel modules - yes this is done without checks that it is loaded. But even if it is not loaded, could it harm to unload it second time? Do you see usecases when these modules are required for an average user?
- make directories (if not exists) /run/dump1090-mutability and /var/log/lighttpd - we've seen cases when these apps failed to start in non-root mode if these directories didn't exist
- chmod world read+write /run/dump1090-mutability to allow both lighttpd and fr24feed (and dump1090 obviously) to access this directory. Could it be done in a more clear way? Sure. And we will definitely return to this after thorough testing.
I would like to say thank you once again and apologise for any inconvenience, but I wouldn't agree that any of the mentioned items are so bad and critical that we can call them "unforgivable". We've moved away from running things as superuser which to my opinion could potentially cause higher risk. We will of course gradually improve things.
Comment