Core: Code integrity failure when modifying .user.ini

Created on 11 Mar 2016 · 7Comments · Source: owncloud/core

Steps to reproduce

Change core's .user.ini
Reload owncloud

Expected behaviour
I should be able to modify an ini file
If .user.ini is to be the acting arbiter of post_max_size and upload_max_filesize on NGINX configurations, then it should not be code signed.. (i.e. You _need_ to change it)

Actual behaviour
Message display at the top of web UI: "There were problems with the code integrity check. More information"

Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results
=======
- core
    - INVALID_HASH
        - .user.ini

Raw output
==========
Array
(
    [core] => Array
        (
            [INVALID_HASH] => Array
                (
                    [.user.ini] => Array
                        (
                            [expected] => 0a557e3cdca4c2e3675deed761d79d109011dcdebbd9c7f6429f1d3476938ec95729543d7384651d1d0c48e26c5024cc5f517445920915a704ea748bdb903c5f
                            [current] => 2cbd840c4ea40edf706fa45ed23836e7e0757630030280a0f97b76d3ae97429361d05138e4484ef4e53b3c37da3d95b5de19785944ccebcae2d8d35f98091f4b
                        )

                )

        )

)

Server configuration

Operating system: CentOS 7

Web server: NGINX 1.9.12

Database: MariaDB

PHP version: PHP 7.0.4

ownCloud version: 9 stable

Updated from an older ownCloud or fresh install: 8.2.2

Where did you install ownCloud from: repositories

Bug core sev3-medium

Source

xenithorb

All 7 comments

Thats the expected behavior. Just use the original .user.ini, rescan from the admin backend and then make your changes afterwards.

ghost on 11 Mar 2016

Can you elaborate on "make your changes afterwards" - that's kind of what I felt like I was doing.

I could find no other way of getting post_max_size and upload_max_filesize to be the value I wanted without editing that.

Just so you're aware, https://doc.owncloud.org/server/9.0/admin_manual/installation/source_installation.html#php-fpm-tips-label

It says the following:

.htaccess notes for Web servers <> Apache

ownCloud comes with its own owncloud/.htaccess file. Because php-fpm can’t read PHP settings in .htaccess these settings and permissions must be set in the owncloud/.user.ini file.

Which is what pointed me to editing that file.

Must be set is pretty clear.

xenithorb on 11 Mar 2016

Hi,

the integrity check is running once after each update/upgrade. So just make this steps:

use all original files from the archive
browse to your admin backend with the "Security & Setup Warnings" telling you that the integrity check is failing
Hit "rescan" within that message
The yellow warning and the Security & Setup Warnings" message will disappear
Modify the .user.ini afterwards

Those steps are also described in the documentation here:

https://doc.owncloud.org/server/9.0/admin_manual/issues/code_signing.html#fixing-invalid-code-integrity-messages

ghost on 11 Mar 2016

👍1

The preferred solution for this for me is to add:

  fastcgi_param PHP_VALUE "user_ini.filename = ";

to the owncloud NGINX configuration (or set what's in quotes in php.ini) - with the understanding that I should be mindful of mimicing the settings contained within .user.ini

This way I am not subject to .user.ini being overwritten (clobbered) by the package manager (even though it probably won't but could), and I also don't have to mess with file integrity.

I think the actual problem stemmed from the fact that I made the .user.ini changes and THEN enabled a plugin that had not been upgraded yet, thus triggering an additional upgrade. (because I can assure you the changes were made after the initial upgrade)

xenithorb on 11 Mar 2016

👍1

@LukasReschke