Allow root owned config.

[Dreamsorcerer]

It would be good to fully support read-only configs, in order to be able to support a setup where the config is owned by root in /etc/nextcloud/ for example. This increases security, and better supports packaging Nextcloud into Linux distributions.

With some minor tweaks to the code, I have successfully managed to run Nextcloud as described, and have managed to perform an upgrade successfully by manually making changes to the config.

In order to accomplish this properly, these are the changes I believe are needed:

• In order to run Nextcloud normally with a root owned config, Nextcloud should check for the owner of the datadirectory instead of the config file (given this is the only thing it should be editing). (Check datadirectory owner, not config owner. #27613, feat: allow to configure php.user #45307)
• Regression in v24+: fix: regression with updating read-only config #44039
• For upgrades, Nextcloud should use the database to store non-user options during the upgrade process, rather than editing the config file.
  • The loglevel could be set in the DB, and then perhaps the lowest value between the config and the DB is the level used. This way the upgrade process can set debuglevel to 0 in the DB, and then unset it after completion, leaving the user's setting alone.
  • maintenance could be set in the DB, with maintenance mode being enabled if the flag is found in either the config or DB. Again, the upgrade can then set this in the DB, and unset it after upgrade.
  • version could be set in the DB. Surely the release number is primarily used to ensure the DB is upgraded? Therefore the value belongs in the DB and not with the user config. (This makes me wonder what might go wrong if someone imports their database from a backup, but are still using the current config file with a newer release number and the imported DB is then in the wrong state.)
• Additionally, Nextcloud should avoid writing default settings to the config. When upgrading, it wanted to write "'theme' = ''", which is the default value if not present.
• If Nextcloud really does need to update a value in the config, it should pause the upgrade and tell the user what value needs to be changed/added and then allow the user to continue the upgrade after manually updating the config.

[nextcloud-bot]

GitMate.io thinks possibly related issues are #6550 (Config 'trusted_proxies'. Allow networks with CIDR), #5117 (unsafe nginx config), #10120 (allow to disable encryption), #10121 (allow to disable encryption), and #10018 (Update root.vue).

[ct-zen]

Neither config nor apps should NEED to be writable except when you want to make changes. At all other times those areas should be locked down to prevent the webserver software from making unwanted/unauthorized changes. This way you are protected from unauthorized changes that may come about through weaknesses in any of the systems involved (code, webserver, php, leaked/weak credentials, etc.).

[flokli]

Also very interested in support for a read-only config through the whole lifecycle of nextcloud (installation, running, upgrading).

We currently run into unwanted side-effects with having the occ maintenance:install and nextcloud itself writing config.php, while overriding some parts in override.config.php (see NixOS/nixpkgs#49783 ).

@Dreamsorcerer As for the issues you mentioned, I think it might help breaking them down to PRs, linking to this issue.

Thinking your ideas further, this would also imply the occ maintenance:install command by default reading database options etc. from the config file instead of command line arguments provided (and not writing to the config file on its own, as it doesn't change when options are being read from there obviously).

[Dreamsorcerer]

@Dreamsorcerer As for the issues you mentioned, I think it might help breaking them down to PRs, linking to this issue.

Of course, but the 4 line patch I linked is the only work I've put into this so far. Certainly doing a separate PR for each step will be useful if someone does start to work on this seriously.

[Kixunil]

I don't think any checks of owners are correct. Checking scripts should only check read access(). (But why check it at all and not just try to read it?) There should be no need for write access.

[Dreamsorcerer]

Write access is needed to complete the upgrade, right? Because it will try to update the apps installed.

[Kixunil]

I mean writes should go to DB. Besides upgrades could be handled by package managers instead. Then write should not be needed.

[Dreamsorcerer]

But an app is a set of files downloaded on the system (in the datadir). To upgrade them, you must overwrite those files with the new app...

[Kixunil]

Apps can be stored in another directory and/or can also be handled by package managers.