Ensure Cacti can support PHP 8

[paulgevers]

PHP8 makes Cacti spit out lots of errors and warnings (but otherwise succeeds)

In Debian Experimental, the default PHP was upgraded to PHP8 to check if its possible to upgrade PHP8 before the Debian Freeze (12 January 2021). It turns out that the testsuite I have for Cacti in the Debian package fails on PHP Errors and Warnings. This means by the way that the web pages seem to be successfully served, as the log check comes last. Although I worry especially about the CSRF errors.

To Reproduce

Recursive web crawl on a cacti site with PHP8 as the running PHP version

An example log can be found here. I'll copy/paste the first part below as that log is recycled after some time. Fresh logs are probably available here.

Expected behavior

No new Error (and ideally no new Warning) messages compared to PHP7.

Desktop

Not applicable

Smartphone

Not applicable

Additional context

Headless server running Debian unstable with php-default packages from experimental.

Unexpected output in /var/log/cacti/cacti.log:
12/12/2020 05:31:28 - ERROR PHP WARNING: ini_set(): Cannot change zlib.output_compression - headers already sent in file: /usr/share/cacti/site/lib/import.php  on line: 260
12/12/2020 05:31:28 - CMDPHP PHP ERROR WARNING Backtrace:  (/usr/share/cacti/cli/import_package.php[133]:import_package(), /lib/import.php[260]:ini_set(), CactiErrorHandler())
12/12/2020 05:31:29 - ERROR PHP WARNING: ini_set(): Cannot change zlib.output_compression - headers already sent in file: /usr/share/cacti/site/lib/import.php  on line: 260
12/12/2020 05:31:29 - CMDPHP PHP ERROR WARNING Backtrace:  (/usr/share/cacti/cli/import_package.php[133]:import_package(), /lib/import.php[260]:ini_set(), CactiErrorHandler())
12/12/2020 05:31:30 - ERROR PHP WARNING: ini_set(): Cannot change zlib.output_compression - headers already sent in file: /usr/share/cacti/site/lib/import.php  on line: 260
12/12/2020 05:31:30 - CMDPHP PHP ERROR WARNING Backtrace:  (/usr/share/cacti/cli/import_package.php[133]:import_package(), /lib/import.php[260]:ini_set(), CactiErrorHandler())
12/12/2020 05:31:32 - ERROR PHP WARNING: ini_set(): Cannot change zlib.output_compression - headers already sent in file: /usr/share/cacti/site/lib/import.php  on line: 260
12/12/2020 05:31:32 - CMDPHP PHP ERROR WARNING Backtrace:  (/usr/share/cacti/cli/import_package.php[133]:import_package(), /lib/import.php[260]:ini_set(), CactiErrorHandler())
12/12/2020 05:31:41 - ERROR PHP WARNING: fopen(/usr/share/cacti/site/include/vendor/csrf/csrf-secret.php): Failed to open stream: Permission denied in file: /usr/share/cacti/site/include/vendor/csrf/csrf-magic.php  on line: 490
12/12/2020 05:31:41 - CMDPHP PHP ERROR WARNING Backtrace:  (/index.php[25]:include(), /include/auth.php[177]:require_once(), /auth_login.php[827]:include_once(), /include/global_session.php[135]:csrf_get_tokens(), /include/vendor/csrf/csrf-magic.php[125]:csrf_get_secret(), /include/vendor/csrf/csrf-magic.php[366]:csrf_writable(), /include/vendor/csrf/csrf-magic.php[490]:fopen(), CactiErrorHandler())
12/12/2020 05:31:41 - ERROR PHP WARNING: fopen(/usr/share/cacti/site/include/vendor/csrf/csrf-secret.php): Failed to open stream: Permission denied in file: /usr/share/cacti/site/include/vendor/csrf/csrf-magic.php  on line: 490
12/12/2020 05:31:41 - CMDPHP PHP ERROR WARNING Backtrace:  (/index.php[25]:include(), /include/auth.php[177]:require_once(), /auth_login.php[827]:include_once(), /include/global_session.php[135]:csrf_get_tokens(), /include/vendor/csrf/csrf-magic.php[140]:csrf_hash(), /include/vendor/csrf/csrf-magic.php[423]:csrf_get_secret(), /include/vendor/csrf/csrf-magic.php[366]:csrf_writable(), /include/vendor/csrf/csrf-magic.php[490]:fopen(), CactiErrorHandler())

[paulgevers]

Maybe relevant note, this log is on arm64, I haven't seen the results yet on amd64.

[TheWitness]

Thanks for the heads up @paulgevers. We'll get these fixed.

[TheWitness]

The csfr-secret issue might be build related?

[TheWitness]

Okay, the zlib issue should be resolved. However, I think that the csrf_magic.php issue might be a build issue. Cacti is supposed to have write access to be able to write the CSRF Secret file. Can you look into how you are doing that currently and report you findings @paulgevers?

[paulgevers]

@TheWitness can you elaborate how this CSRF Secret file is supposed to work. It seems that it's unused in Debian, as the default file (which I don't change in the packaging) doesn't exist and indeed the default location isn't writable. I haven't heard complaints yet about stuff not working, so I wonder what this file is supposed to achieve.

[TheWitness]

@paulgevers, it's the file that holds the post encryption key. It's pointed to in the config.php. It get's created at install time. So, if the default is used, the web server needs RW access to the vendor/csrf folder.

It's defaulted to $CACTI_TOP/include/vendor/csrf. So, but you can move it to /etc/cacti where it belongs using the setting. Let me know if you need more details.

The config.php variables is: $path_csrf_secret = '/etc/cacti/csrf-secret.php';

[paulgevers]

@TheWitness does this means that if it's missing, there's no encryption? In that case I guess I have created a security issue in the Debian packaging.

[TheWitness]

I don't think so. See if the file 'csrf-secret.php' is found in $CACTI_TOP/include/vendor/csrf/.

[paulgevers]

paul@mulciber ~ $ find /usr/share/cacti -name csrf-secret.php
paul@mulciber ~ $

The file doesn't exist.

[TheWitness]

Hmm, if that's after install, it could be a problem. Let me check the code.

Looks like unless you are setting it somewhere, yea, there is a problem. It still verifies that the post came from the same host, just won't use the key to make it even more secure.

[paulgevers]

@TheWitness just in case you didn't realize, in Debian we don't run the Cacti install process (because, at least in the past, that was doing all kind of things we handle at the package level).

[TheWitness]

You can just call the csrf_generate_secret() in your installer process and store it in the correct location then. No worries.

[TheWitness]

Maybe we should have a CLI for this, to set/reset it from time to time.

[paulgevers]

@TheWitness sure, I can fix it in future version, but, how bad is it for the installations out there that don't have this file?

[TheWitness]

Maybe a CLI won't hurt for them, then you can either issue a bulletin, or app note. What do you think?

[paulgevers]

O, for security updates, there's always an announcement from the security team. I'm more wondering is it so bad that I need to request a CVE and get an upload to stable via the security team.

[TheWitness]

I think that's on you regardless, but we can support by giving a cli for a quick fix.

[TheWitness]

We should log, and also have an admin alert in the case it's missing. Have to put a timer on it as that file is always loaded.

[netniV]

I think @paulgevers in the past, you had to do a lot of our work to install automatically without a user. However, we do have the CLI installer now that can do that work for you to keep both a command line and web installation using the same code.

As for the CSRF secret, if one exists, then it is used as an extra security layer but it does not NEED to exist (despite the thoughts to the contrary). If you wish to create a secret, it will make things more secure but I don't believe there is a hole without it.

[paulgevers]

@TheWitness @netniV thanks for all the information. I'll look into running the CLI installer during the Debian package install process.

[TheWitness]

@paulgevers, thanks for your continued support. I have committed a CLI script referenced in this commit.

#4012

Feel free to close this when you are comfortable that you can move forward.

Larry

[paulgevers]

Let's close it for now. I'll report back when I have fixed the package and there are still issues.