Repository navigation
[SOAP] Temporary WSDL cache files not being deleted #12838
Description
Description
Hi there,
After upgrading some servers from PHP 8.1.25 to 8.1.26 I started receiving alerts that their disk usage was increasing unusually fast due to thousands of tmp.wsdl.* files being created in the WSDL cache folder.
From what I've seen those temporary files were added in #12469 but I think it may be related to another issue I had before.
PHP scripts from my app are owned by an user called admin and may be executed by two different users :
admin(CLI)www-data(PHP-FPM).
In both cases SOAP APIs may be called which will result in the WSDL cache being populated.
From my understanding, the filenames for those files depend on a php_get_current_user() call which doesn't return the process owner but the owner of the script, which means that in both cases (CLI or PHP-FPM) the files will have the same name.
Since - at least in my case - they are created in the /tmp directory with 600 permissions, only the owner of the process that was used to create them can also read them. So, I basically end-up with files called wsdl-admin-* owned by the first user that populated the WSDL cache (ex: admin) and not readable by the other one (ex: www-data). I'm not sure why it worked before 8.1.26, I'm guessing that it probably didn't but failed silently.
What I think happens next is that the new code from #12469 tries to move the tmp.wsdl.* files to wsdl-admin-<hash> but does not have the permission to do so.
So, two questions:
- is there a reason the cache files are named based on the script file owner and not the PHP process owner?
- shouldn't the
tmp.wsdl.*files be removed if they could not be renamed?
PHP Version
PHP 8.1.26
Operating System
Ubuntu 20.04
Activity
ndossche commentedon Nov 30, 2023
Thanks for the report! Your analysis seems right.
It's actually even worse. In case the SAPI has set up a custom user to run under then it will return that user... So it's quite inconsistent. (except on Windows where it will always return the current user).
Seems like an oversight to me. I'm not going to touch this for stable branches, but I'll take a look to fix this on master.
Yeah that should fix your issue.
Yeah the caching just didn't work before. This should be fixable by taking the right username, something that I'll look into for master. For stable branches I'll make sure the temp files are removed.
Fix phpGH-12838: [SOAP] Temporary WSDL cache files not being deleted
Lyrkan commentedon Dec 1, 2023
Hi @nielsdos,
Thanks for taking care of it.
For now as a workaround I moved cache files to their own directory and handle permissions on them using ACLs, seems to do the trick :)
Fix GH-12838: [SOAP] Temporary WSDL cache files not being deleted
Merge branch 'PHP-8.2' into PHP-8.3
Merge branch 'PHP-8.3'
nikoelgatito commentedon May 6, 2025
Hi @nielsdos,
We recently updated an application to use php 8.1 and we are experiencing a similar issue.
After reviewing the content of the file below for the latest php 8.1 version, I can see that the commit 4eee81b was never applied.
Affected File:
https://github.com/php/php-src/blob/php-8.1.32/ext/soap/php_sdl.c
Is there a specific reason why this commit never made it to the stable php 8.1 version?
ndossche commentedon May 6, 2025
Support for 8.1 ended before the fix was made.
nikoelgatito commentedon May 6, 2025
I appreciate your quick response.
Indeed, I can see that the active support period ended 5 days before this issue was reported.
Since this issue may result in a space saturation of the /tmp directory, which would be causing a system crash, could it be considered a security fix?
ndossche commentedon May 6, 2025
I don't think so as it doesn't fit the threat model.
However, we have a policy nowadays of allowing certain backports to security releases in some cases, so we could ask the release managers.
nikoelgatito commentedon May 6, 2025
Thank you for sharing this information.
As some applications perform large amounts of SOAP requests in a short period of time, caching is particularly important and it is filling up the /tmp directory quickly.
Considering that this change is exceptionally small and has been in use for quite some time in versions 8.2+, backporting it should not come with any risk.
Therefore, it would be greatly appreciated if you could ask the release managers if they could allow this backport.
ndossche commentedon May 6, 2025
Cc @ramsey @patrickallaert if you agree I'll cherry pick the regression fix into 8.1.
bukka commentedon May 9, 2025
Technically this is not allowed in year 4 as per https://github.com/php/policies/blob/main/release-process.rst#bug-fix-and-security-releases . So RM cannot currently make such exception.
I think it would make sense to update policy as we also started making some build updates and it would make sense to backport fixes like this. I will look into it as I wanted to add some other updates for some time.
bukka commentedon May 9, 2025
Ok this gave me a bit motivation to do that RFC so here it is: https://wiki.php.net/rfc/policy-release-process-update
Fix bug #61094: Wrong WSDL cache file name