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