Project

General

Profile

Actions

Bug #102736

open

Install Tool Configuration Presets broken for image handling settings with debug mode enabled

Added by Arne Bracht over 1 year ago. Updated about 1 month ago.

Status:
Accepted
Priority:
Must have
Assignee:
-
Category:
Backend User Interface
Target version:
-
Start date:
2024-01-01
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
13
PHP Version:
8.3
Tags:
Configuration Presets
Complexity:
Is Regression:
No
Sprint Focus:

Description

Hello,

Upgrade from 11.5.33auf 12.4.9.

If "Configuration Presets" ist set to Debug the "Configuration Presets" is broken. It returns an AJAX Error:

Core: Error handler (BE): PHP Warning: file_exists(): open_basedir restriction in effect. File(/opt/local/bin/identify) is not within the allowed path(s): (/usr/bin/) in /typo3_src-12.4.9/typo3/sysext/install/Classes/Configuration/Image/ImageMagick6Preset.php line 81
Core: Error handler (BE): PHP Warning: file_exists(): open_basedir restriction in effect. File(/opt/local/bin/gm) is not within the allowed path(s): (/usr/bin/) in /typo3_src-12.4.9/typo3/sysext/install/Classes/Configuration/Image/GraphicsMagickPreset.php line 77

Temporär solution set "Configure Installation-Wide Options" -> [GFX][processor_path] from /usr/bin/ to /usr/bin. Then "Configuration Presets" load without error. Set Debug mode to off an then you can use "Configuration Presets" again to switch preset between GraphicsMagick and ImageMagick6.


Files

patch-102736.diff (1.26 KB) patch-102736.diff use Symfony ExecutableFinder::find instead of file_exists Franz Holzinger, 2025-05-13 12:14

Related issues 3 (1 open2 closed)

Related to TYPO3 Core - Bug #100021: Incorrect path because of absolutely reference file(s) in typo3/cms-dashboard plus it causes open_basedir warningsNeeds Feedback2023-02-23

Actions
Related to TYPO3 Core - Bug #101350: open_basedir restriction in effectResolved2023-07-14

Actions
Is duplicate of TYPO3 Core - Bug #101778: Configuration Presets open_basedirClosed2023-08-28

Actions
Actions #1

Updated by Arne Bracht over 1 year ago

So, the error comes from:

if (!file_exists($binaryPath) || !is_executable($binaryPath))
In Debug mode the php warning breaks the preset setup.

What about this suggestion: Ad a if(@is_readable($path)) to avoid the warning, befor the file_exists check? Works in both files ImageMagick6Preset.php and GraphicsMagickPreset.php Sorry that I don't have the knowledge to make it as a patch request.

    protected function findImageMagick6InPaths(array $searchPaths)
    {
        $result = false;
        foreach ($searchPaths as $path) {
            if (Environment::isWindows()) {
                $executable = 'identify.exe';

                if (!@is_file($path . $executable)) {
                    $executable = 'magick.exe';
                }
            } else {
                $executable = 'identify';
            }

            if(@is_readable($path)) {
                    $binaryPath = $path . $executable;
                    if (!file_exists($binaryPath) || !is_executable($binaryPath)) {
                        continue;
                    }

                    $command = escapeshellarg($binaryPath) . ' -version';
                    $executingResult = [];
                    CommandUtility::exec($command, $executingResult);
                    // First line of exec command should contain string GraphicsMagick
                    $firstResultLine = array_shift($executingResult);
                    // Example: "Version: ImageMagick 6.6.0-4 2012-05-02 Q16 http://www.imagemagick.org" 
                    if (is_string($firstResultLine) && str_contains($firstResultLine, 'ImageMagick')) {
                        [, $version] = explode('ImageMagick', $firstResultLine);
                        // Example: "6.6.0-4" 
                        [$version] = explode(' ', trim($version));
                        if (version_compare($version, '6.0.0') >= 0) {
                            $this->foundPath = $path;
                            $result = true;
                            break;
                        }
                    }
            }
        }
        return $result;
    }
Actions #2

Updated by Stefan Bürk over 1 year ago

  • Assignee set to Stefan Bürk

Simply suppressing the warning is not a real solution, and should only be used
where there is absolutly no way arround. Not sure about a proper solution directly,
but will put it on my list to recheck this and create a patch then.

Actions #3

Updated by Garvin Hicking about 1 year ago

  • Is duplicate of Bug #101778: Configuration Presets open_basedir added
Actions #4

Updated by Vincent Mans 12 months ago

Here too, in 12.4.15, PHP8.3

The same error.

Priority should be MUST since it breaks the Configuration Presets!

Actions #5

Updated by Martin Weymayer 11 months ago

TYPO3 12.4.17, PHP 8.2 same probleme

Actions #6

Updated by Garvin Hicking 11 months ago · Edited

  • Status changed from New to Closed
Actions #7

Updated by Garvin Hicking 11 months ago

  • Related to Bug #100021: Incorrect path because of absolutely reference file(s) in typo3/cms-dashboard plus it causes open_basedir warnings added
Actions #8

Updated by Garvin Hicking 11 months ago

  • Status changed from Closed to Accepted
  • Priority changed from Should have to Must have

(This issue was falsely closed due to its dupe. Re-opening now and adapting to the other issue)

Actions #9

Updated by Marco Kuprat 6 months ago

This issue has been around since a while. Any update?

Actions #10

Updated by Garvin Hicking 6 months ago

  • Related to Bug #101350: open_basedir restriction in effect added
Actions #11

Updated by Vincent Mans 4 months ago

  • TYPO3 Version changed from 12 to 13
  • PHP Version changed from 8.2 to 8.3

And it still lingers on in version 13.4.5.

To be clear about the severity :

Switching back from Debug to Live preset is impossible. How can this error still exist?

Actions #12

Updated by Garvin Hicking 4 months ago

How can this error still exist?

Because no one has invested their free time yet as there are many other issues. If you can offer a proper patch, that would be very helpful, thank you!

Actions #13

Updated by Vincent Mans 4 months ago

What kind of response is this? You just closed it a while ago without any reason.

I know how to solve it, but not how to patch it, sorry, I am not a programmer.

This bug exists since version 11. Perhaps even 10. TYPO3 lacks popularity in some regions, this is typically a reason.

Therefore I raised the Priority status, and it must remain listed.

Actions #14

Updated by Garvin Hicking 4 months ago

Vincent Mans wrote in #note-13:

What kind of response is this?

An honest one reflecting your base-level aggressiveness.

You just closed it a while ago without any reason.

This issue is open, it was re-opened with a comment.

Actions #15

Updated by Stefan Bürk 4 months ago

  • Assignee deleted (Stefan Bürk)
Actions #16

Updated by Vincent Mans 4 months ago

Sorry for being insensitive. It was a quick writing, and an honest question.

Actions #17

Updated by Franz Holzinger about 1 month ago

Look here:

https://github.com/symfony/symfony/issues/41006
https://github.com/symfony/symfony/pull/47422

Quote:

Console::findExecutable()'s responsibility is to find an executable which can be called with a Symfony Process or by PHP's functions like exec, system etc.
The goal of PHP's open_basedir config is to restrict reading / writing files within PHP processes. Imho this is completely independent of finding an executable.

If PHP's intention was to restrict executing applications which are not present in open_basedir's paths, it would have been implemented there.

The attached patch fixes this issue.

Actions

Also available in: Atom PDF