Update Permission Nextcloud 17 Update

ℹ️ Support
1

Steps to reproduce

  1. Nextcloud Update
  2. set permissions before update
  3. set permissions after update

Expected behaviour

in previous versions of NC, we had to configure the write permissions before update and change them back after upgrade. What shall we do in Version 17? There is no information regarding the permission issue.

Further are there other NC hardening advises regarding NC 17 e. directory permissions?

Actual behaviour

Set Update Permissions

General server configuration

Operating system: Ubuntu 18.04.

Web server: nginx

Database: postgres

PHP version: PHP 7.2.24-0ubuntu0.18.04.1 (cli) (built: Oct 28 2019 12:07:07) ( NTS )

PHP-modules loaded

Nextcloud configuration

Nextcloud version: 17.0.0

Updated from an older Nextcloud/ownCloud or fresh install: Fresh install

Where did you install Nextcloud from:

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

Signing statusEnabled appsDisabled apps

Nextcloud configuration:

<?php $CONFIG = array ( 'passwordsalt' => '****', 'secret' => '*****', 'trusted_domains' => array ( 1 => 'boxname', 2 => 'somename.somedomain.com', ), 'datadirectory' => '/opt/data', 'tempdirectory' => '/opt/data/upload-temp', 'dbtype' => 'pgsql', 'version' => '17.0.0.9', 'overwrite.cli.url' => 'https://somename.somedomain.com', 'dbname' => 'nextcloud', 'dbhost' => 'localhost', 'dbtableprefix' => 'oc_', 'dbuser' => 'someuser', 'dbpassword' => '*****', 'installed' => true, 'instanceid' => 'ocbh6xoav4ik', 'maintenance' => false, 'default_language' => 'de', 'default_locale' => 'de_DE', 'session_lifetime' => 300, 'remember_login_cookie_lifetime' => 0, 'session_keepalive' => false, 'mail_smtpmode' => 'smtp', 'mail_sendmailmode' => 'smtp', 'mail_from_address' => 'austausch', 'mail_domain' => 'hisolutions.com', 'mail_smtpdebug' => true, 'mail_smtphost' => 'mail.somedomain.com', 'mail_smtpport' => '25', 'enable_previews' => false, 'overwriteprotocol' => 'https', 'trashbin_retention_obligation' => 'auto, 30', 'loglevel' => 3, 'logdateformat' => 'F d, Y H:i:s', 'logfilemode' => 0640, 'log_type' => 'file', 'logfile' => '/var/log//nextcloud/nextcloud.log',
2

The updater app obviously need write permissions. With the updater app, I’m not sure if they have the same hardening advices, there would be one more manual step which might be a bit different depending on the setup. The benefits, I mean if someone manages to access stuff on your server with webserver permissions, they can already access user data. Therefore, I wouldn’t wonder if it weren’t in the documentation any more.
But you can continue like that, the code files can be just readable (except during upgrade).

One thing to avoid that the code is writable by other users (or even worse on the data folder).

3

Hello and thanks for the response,

I cannot clearly understand, how the permissions should be before updating and after the update has finished. I mean the permissiosn for /var/www/nextcloud. Actual the are
drwxr-xr-x www-data www-data. Or kann I do the update via cli as root, without changing anything?

Rgds

Haydar

4

It was topic of discussion earlier that those strict UNIX permissions are no real security benefit. Furthermore it was planned to add some automated update feature, which cannot work without R/W permissions and the security benefit of an updated Nextcloud was evaluated higher than the one of strict permissions.

It is a matter of Nextcloud itself to not allow any unauthorized writes to its scripts, which can be assumed guaranteed. Only other reason to deny R/W would be if you run another insecure website, which enables unauthorized writes to the Nextcloud files, on the same webserver :thinking:.

So 755/644 www-data:www-data is fine :wink:.

About CLI update, there is this /path/to/nextcloud/updater/updater.phar which can be called via php command from console, but I guess it denies to be called with another use than www-data. But could be tested.

5

Hello,

ok I did the update to 17.0.1 manually via tarball, it worked like a charm. Thanks

for the help