cron.php does not honor config_is_read_only

[AndreasBilke]

Steps to reproduce

1. set config_is_read_only = true in config.php
2. chown -R root:www-data config/
3. run php -f <fqpn>/cron.php as www-data user

Expected behaviour

cron script should run without problems.

Actual behaviour

1. cron script does only print error message but does not use error exit codes (it returns 0)
2. cron script print (and execute nothing):

Console has to be executed with the same user as the web server is operated
Current user: www-data
Web server user: root

But running this as root is not the brightest idea. Cron script should honor config_is_read_only

Server configuration

Operating system:
Debian GNU/Linux 8.3 (jessie)

Web server:
nginx 1.6.2-5+deb8u1

Database:
PostgreSQL 9.4.6-0+deb8u1

PHP version:
php 5.6.17+dfsg-0+deb8u1

ownCloud version: (see ownCloud admin page)
9.0.0

Updated from an older ownCloud or fresh install:
Manual update from 8.2.2

Where did you install ownCloud from:
tarball

Signing status (ownCloud 9.0 and above):

No errors have been found.

List of activated apps:

Enabled:
  - calendar: 1.0
  - contacts: 1.0.0.0
  - dav: 0.1.5
  - federatedfilesharing: 0.1.0
  - files: 1.4.4
  - files_sharing: 0.9.1
  - notifications: 0.2.3
  - provisioning_api: 0.4.1
  - systemtags: 0.2
  - updatenotification: 0.1.0
  - user_ldap: 0.8.0

The content of config/config.php:

{
    "system": {
        "instanceid": "ocf577ccbb53",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "9.0.0.19",
        "dbname": "cloud",
        "dbhost": "localhost",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "forcessl": true,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "ldapIgnoreNamingRules": false,
        "log_type": "owncloud",
        "log_rotate_size": 10485760,
        "cron_log": true,
        "maintenance": false,
        "defaultapp": "calendar",
        "mail_smtphost": "localhost",
        "mail_smtpport": "25",
        "theme": "",
        "forceSSLforSubdomains": true,
        "loglevel": 1,
        "filelocking.enabled": "true",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "localhost",
            "port": 6379,
            "timeout": 0,
            "password": "***REMOVED SENSITIVE VALUE***"
        },
        "asset-pipeline.enabled": false,
        "config_is_read_only": true
    }
}

Are you using external storage, if yes which one: local/smb/sftp/...
No

Are you using encryption: yes/no
No

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
LDAP

Client configuration

Browser:
Firefox

Operating system:
Arch Linux

[Phiber2000]

As temporary workaround, you can chown www-data:www-data config/config.php and cron.php will run.

[Phiber2000]

Forget that 'single' file. Following the specifications, you have to chown -R www-data:www-data config/.
See https://doc.owncloud.org/server/9.0/admin_manual/installation/installation_wizard.html#setting-strong-directory-permissions.

[AndreasBilke]

Of course, but that would allow the www-data user to modify the file
anyway.

[Phiber2000]

That's why there is a config_is_read_only parameter... ;)
Additionally you could write-protect the file.

[AndreasBilke]

Yes, but config_is_read_only is only a flag. If you have malicious/bad
code, this flag does not matter ;)

But write-protecting is a good hint and workaround.

[PVince81]

PRs welcome

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[PVince81]

Feel free to reopen if this issue still exists with 10.0.5 RC3

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.