Suggest optional security hardening in systemd service

[JustArchi]

☑️ Resolves

This is similar to pull request nextcloud/notify_push#704 that I opened for notify_push. I didn't find any existing issue opened that this PR resolves.

In particular, this PR adds a few additional [Service] systemd entries that are wanted for people that want to ensure additional security bulletproofing on their system.

I verified that nextcloud's cron service works properly with no errors or warnings upon applying. I've been using this configuration on my own machine since a few weeks now and everything is working properly - most importantly, nextcloud reports new version as available for updating, which proves that the most crucial cron functionality works properly.

I believe this is worthy addition. If you want to make it truly optional, I can also comment out all of those entries, leaving them up to the user to enable. Considering the fact that it doesn't create any apparent issues however, I believe they should be enabled by default.

Thanks in advance for considering this PR.

🖼️ Screenshots

✅ Checklist

• I have built the documentation locally and reviewed the output
• Screenshots are included for visual changes
• I have not moved or renamed pages (or added a redirect if I did)
• I have run codespell or similar and addressed any spelling issues

[skjnldsv]

Hey! Thanks for this PR!
Could you provide some source for those parameters ? I have no knowledge on the matter, but I feel it would be better with some source or comments on why they're good addition for hardening :)

[JustArchi]

Hey @skjnldsv

All of the settings are explained in systemd documentation, i.e. https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html

Regardless, I'm attaching screenshot of systemd-analyze security which gives quick summary of enabled settings. I don't believe majority of users require links/comments directly in the systemd unit file, same how we don't explain other stuff there. It'd be extremely verbose otherwise, and I didn't see any other services doing that either.

[skjnldsv]

@JustArchi then please add that link to the docs. Our documentation should be as straightforward as possible. An admin should not have to search deeper on other docs to understand why we do X or y (ideally of course)

[skjnldsv]

I don't believe majority of users require links/comments directly in the systemd unit file, same how we don't explain other stuff there. It'd be extremely verbose otherwise, and I didn't see any other services doing that either.

Then a bit more explanations is still warranted I think. Even if we don't add that to the systemd file, we need to be more transparent

[JustArchi]

Sure, done.

[skjnldsv]

So, I think we're getting close to approval, but there is still potentially breaking options that I think warrant a .. warning::

These options will silently break common Nextcloud setups:

• PrivateMounts=yes isolates the mount namespace like we discussed. Any external storage (NFS, SMB, local mounts via config.php) that the cron job tries to scan will be invisible. This is a real regression for many admins, not just edge-case.
• PrivateUsers=yes creates a user namespace. File permission checks on the host filesystem (e.g., data directory owned by www-data) can fail because the UID mapping may not carry through to bind-mounted paths.
• UMask=0077 creates files/dirs as 600/700. If cron writes temp files or cache that the web server process reads (both running as www-data but potentially different forks), this can cause permission errors. Also breaks setups where the data dir needs group access.

[JustArchi]

@skjnldsv I've agreed with and done the following:

• Clarified description of security hardening
• Brought back system protection commented out with description
• Made private mounts commented out with description
• Made private users and umask commented out with description

Still wondering if UMask can ever become a problem for same-user scenario, i.e. your case:

If cron writes temp files or cache that the web server process reads (both running as www-data but potentially different forks), this can cause permission errors.

Because this can happen only in one very specific edge case:

• Cron user running as nextcloud user cloud (or similar) writes a file
• That is expected to be directly served by nginx user www-data (or similar)

Only in this case nginx will not be able to serve the file directly, will resort to php engine, and that one will resolve the file correctly.

I ran find -type d -perm 700 -o -type f -perm 600 in my setup, and found barely a few entries like:

./appdata_occvcx132fiy/preview/2/4/6/a/0/3/3/1260272
./appdata_occvcx132fiy/preview/2/4/6/a/0/3/3/1260272/3072-4096-max.jpg

But this is appdata, data directory, nginx does not serve files from there directly, ever, and cron should never write inside nextcloud's root directory to the best of my knowledge (it can even be read-only, so this UMask will be the last problem in this case, as a lot of setups have those files owned by e.g. root and cron can't write there anyway).

Therefore, I believe current version is correct in regards to your review - feel free to give it another shot 👍