Skip to content

fix: disable the phar wrapper globally - #41406

Merged
DeepDiver1975 merged 2 commits into
masterfrom
disable_phar_wrapper
Sep 18, 2025
Merged

fix: disable the phar wrapper globally#41406
DeepDiver1975 merged 2 commits into
masterfrom
disable_phar_wrapper

Conversation

@jvillafanez

Copy link
Copy Markdown
Member

Description

Phar wrapper won't be allowed by default. If needed, consider to enable it, do your thing, and disable it again; limiting the exposure to what is strictly needed.

Related Issue

  • Fixes <issue_link>

Motivation and Context

How Has This Been Tested?

Manually tested, weird things with ".phar" files don't happen.

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Database schema changes (next release will require increase of minor version instead of patch)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Technical debt
  • Tests only (no source changes)

Checklist:

  • Code changes
  • Unit tests added
  • Acceptance tests added
  • Documentation ticket raised:
  • Changelog item, see TEMPLATE

@jvillafanez jvillafanez self-assigned this Sep 16, 2025
@update-docs

update-docs Bot commented Sep 16, 2025

Copy link
Copy Markdown

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

This is needed because phpstan seems to require the phar wrapper to
work. Phpstan is currently bootstrapping the lib/kernel.php file, so we
can't disable the phar wrapper there.
@sonarqubecloud

Copy link
Copy Markdown

@jvillafanez jvillafanez mentioned this pull request Sep 17, 2025
11 tasks
@DeepDiver1975
DeepDiver1975 merged commit 9bf9194 into master Sep 18, 2025
6 checks passed
@jvillafanez
jvillafanez deleted the disable_phar_wrapper branch September 18, 2025 10:04
Comment thread lib/kernel.php

// disable phar handler in web requests
if (!self::$CLI) {
stream_wrapper_unregister("phar");

@UnitedMarsupials UnitedMarsupials Dec 8, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I now get an error logged by this for every request:

[Mon Dec 08 11:22:57.365104 2025] [proxy_fcgi:error] [pid 86763] [client 192.168.1.10:33223] AH01071: Got error 'PHP message: PHP Warning:  stream_wrapper_unregister(): Unable to unregister protocol phar:// in /opt/www/owncloud/lib/kernel.php on line 574'
[Mon Dec 08 11:22:57.365212 2025] [proxy:debug] [pid 86763] proxy_util.c(2832): AH00943: FCGI: has released connection for (*:80)

The log was very noisy, so I modified the code thus:

--- lib/kernel.php	2025-07-03 09:54:27.000000000 -0400
+++ lib/kernel.php	2025-12-08 12:00:22.079292000 -0500
@@ -571,5 +571,5 @@
 
 		// disable phar handler in web requests
-		if (!self::$CLI) {
+		if (!self::$CLI and in_array('phar', stream_get_wrappers())) {
 			stream_wrapper_unregister("phar");
 		}

This helped...

I don't like this creation — and checking — a dictionary for every request, but logging an error is even costlier. Maybe, there is a better way of determining, whether the phar-wrapper is registered in the first place...

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants