Possible PHAR Execution Restriction in HestiaCP (osTicket Plugins Not Loading)

Hello,

I am running a server with HestiaCP and recently installed osTicket on one of the domains. I noticed an issue related to PHP .phar files and wanted to check if there might be any restrictions in the server configuration.

Environment

  • Control Panel: HestiaCP

  • Web Server: Apache (default Hestia stack)

  • OS: Linux VPS

  • PHP Versions Tested:

    • PHP 8.4

    • PHP 8.3

    • PHP 8.2

Issue

osTicket plugins are distributed as .phar files. When I upload the .phar plugin through the osTicket admin interface or place the .phar file directly in the plugin directory, the plugin does not appear in the system.

However, when I manually extract the .phar archive outside of HestiaCP and copy the extracted plugin folder into the plugin directory, the plugin works correctly and appears in the osTicket plugin list.

This suggests the application itself works correctly, but the server may not be allowing .phar archives to execute or be read properly.

Things I Checked

PHAR extension appears to be enabled:

php -m | grep phar

returns:

Phar

My Question

Could HestiaCP or its default configuration block or restrict .phar execution in any of the following ways?

Possible areas I am wondering about:

  • open_basedir restrictions

  • disabled PHP functions

  • phar.readonly settings

  • Apache or PHP-FPM security policies

  • mod_security rules

  • any HestiaCP security hardening related to .phar

Is there any recommended configuration in HestiaCP to allow PHP applications to load .phar files properly?

Thank you for any guidance.

Hi,

I’ve tested it with a test phar file and it works fine using Nginx+Apache (default templates) and PHP 8.3 (default).

I don’t know how osTicket manages those phar files but maybe you must disable phar.readonly. To do so, edit the php.ini for the PHP version your site is using (example: /etc/php/8.3/fpm/php.ini) and add phar.readonly = Off in [Phar] section. After that, restart the php8.3-fpm service.

You should also check the web site log.

1 Like

Hi,

Thank you for testing and for the suggestion.

I checked the phar.readonly setting in the PHP configuration used by my site.

Current value:

phar.readonly = On

From what I understand, this setting mainly prevents creating PHAR archives, but it should not normally prevent reading or executing existing .phar files.

However, I will test changing it to:

phar.readonly = Off

and restart the php-fpm service to see if it changes the behavior.

For reference, the current behavior is:

  • Uploading a .phar plugin in osTicket → plugin does not appear

  • Copying the .phar file directly to /include/plugins/ → plugin still does not appear

  • Manually extracting the .phar archive and placing the extracted folder in /include/plugins/ → plugin works correctly

So the plugin itself appears to work once extracted.

I will also check the website error logs to see if anything related to .phar loading appears there.

I’ll update the thread after testing the phar.readonly change.

Thank you for your help.

1 Like