Code integrity failure when modifying .user.ini #23144

Closed
xenithorb opened this Issue Mar 11, 2016 · 6 comments

Projects

None yet

4 participants

@xenithorb

Steps to reproduce

  1. Change core's .user.ini
  2. Reload owncloud

Expected behaviour

  1. I should be able to modify an ini file
  2. 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

  1. 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

@ghost
ghost commented Mar 11, 2016

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

@xenithorb

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.

@ghost
ghost commented Mar 11, 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

@xenithorb

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)

@PVince81
Collaborator
@PVince81 PVince81 added this to the 9.0.1-current-maintenance milestone Mar 14, 2016
@PVince81 PVince81 added the bug label Mar 14, 2016
@DeepDiver1975 DeepDiver1975 changed the title from Code integrity failure when modifying .user.ini to Code integrity failure when modifying .user.ini Mar 15, 2016
@LukasReschke
Member

#23250 will have some more failsafes against such cases.

@ghost Unknown referenced this issue Apr 4, 2016
Closed

invalid_hash .htaccess .user.ini #23765

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment