DietPi-Software | Sonarr/Radarr/Lidarr: Allow service writes to /media

[ghost]

Remove these service arguments because it causes confusion if you install sonarr or radarr via dietpi-software but have your drive mounted in /media

Hardening

#ProtectSystem=strict
#ProtectHome=true
#PrivateDevices=true
#ProtectKernelTunables=true
#ProtectControlGroups=true
#ReadWritePaths=/opt/NzbDrone /mnt /var/log/sonarr /tmp

Also like a dev from radarr/sonarr its rubbish if you have good permissions anyway, and it just creates a lot of confusion if you dont have it well documented about what it does.

[MichaIng]

@ricardoandren
Many thanks for your request and feedback.

As a rule of thumb: If you face issues with software that was installed via dietpi-software, report them here first, so we can see if it has to do with our implementation or is indeed an issue of the upstream software. This is the same when you install an APT package from the Debian repo: Report the error first at bugs.debian.org, so the package maintainers can check if it's with their implementation (compiled in or skipped features, systemd unit and config design, hardenings, pre-defined AppArmor/SELinux rules or not etc. etc.) and only in case not, forward it to the software devs. That saves the software devs a lot of time and nerves since they usually start thinking from their own build or install instructions, reasonably, and end-users might not be able to provide the exact details about the implementation, which would help to debug the issue. And we would have sorted your issues within minutes, since we have indeed thought through this hardenings for a while 😉.

Now coming to the "rubbish", which is a simple failsafe protection against mistakes from users, the system (us or Debian), runtime system devs (mono in this case), the software devs, or any other of the huge amount of possible sources, and of course another layer that protects against wanted harm from who or wherever it is coming from. Enabling exactly these systemd unit hardenings is found quite often, first match e.g. here from Jackett devs: https://github.com/Jackett/Jackett/wiki/systemd-service

if you have good permissions anyway

The "if" is why we have it in place 😉.

When offering automated software installs, which addresses inexperienced users more then experienced ones, then a bulletproof security has even more relevance. Yeah the systemd unit hardenings are by far not the most important place to being with, since DietPi has a bunch of other places where changes could bring a much greater security improve, but they are simple, easy to implement and completely painless, indeed besides when it's about custom directories for downloaders and media organisers.

I was exactly thinking about adding /media to the ReadWritePaths as well, however it is actually intended for plug and play auto mounted disks and USB sticks to be used by the system, not for manual mounts. And we did/do document and inform about it where we can and provide easy instructions to add custom media paths:

• Prompt during DietPi-Update: https://github.com/MichaIng/DietPi/blob/master/dietpi/patch_file#L2355-L2365
• Online docs: https://dietpi.com/phpbb/viewtopic.php?p=7455#p7455
• Changelog: https://github.com/MichaIng/DietPi/blob/master/CHANGELOG.txt#L59

Okay but I agree that the security benefit of blocking write access to /media is pretty tiny, while it is the second most used location for mounts, hence for media files and downloads often as well. I'll add it to the list with DietPi v6.31.

[ghost]

Hello Michalng, wouldnt a whiptail screen during the installation of lidarr/sonarr/radarr about the mounts (if people use unusual places to mount their drive) be better, if I saw such screen (since the prompt during dietpi-update is only during dietpi-update) I wouldve probably been saved from 3 hours of headache.

[MichaIng]

I added /media to the list btw: 7a4350f

wouldnt a whiptail screen during the installation of lidarr/sonarr/radarr about the mounts

Probably a nice idea is to show a list of links for the online docs of all installed software titles after the install has finished. Generally these are intended to be reviewed by users, containing first run access info like URL path and in case port, setup wizard instructions, currently known issues and such things. When touching them, I tend to add debug infos, where/how to find logs, official docs and source code. Also a simplification of the online docs URLs would be great, e.g. dietpi.com/software/sonarr to bring you to our Sonarr docs, instead of "https://dietpi.com/phpbb/viewtopic.php?p=7455#p7455".
I'll do some rewrite rules for the webserver.

In theory, but that is now a bid more future/maybe work, the docs could be downloaded and shown on in the whiptail menu directly. E.g. you have a list of just installed/reinstalled software titles presented as menu right after it has finished. Selecting one downloads the docs as plain text and shows them scrollable right in your whiptail. So no need to open a browser. Format likely looks bad at start, I guess the docs would require some rework then, but they anyway do at least for some software titles.