Bug #98545
closedfile_exists(): open_basedir restriction in effect
Added by Benedikt Imminger about 2 years ago. Updated 5 months ago.
100%
Description
Issue is related to https://forge.typo3.org/issues/98152
Issue was marked as resolved, but the issue still seems to exist (for at least 2 users)
- Open forms backend module
- Open protocol: "PHP Warning: file_exists(): open_basedir restriction in effect. File(/typo3/sysext/form/Resources/Public/Css/form.css) is not within the allowed path(s)"
see: https://github.com/TYPO3-CMS/form/blob/v11.5.16/Resources/Private/Backend/Layouts/FormManager.html#L2
FormManager.html was shipped with 11.5.16 but has been removed since then
Also happens in the backend module of EXT:formlog which integrates the CSS files like this:
https://github.com/pagemachine/typo3-formlog/blob/master/Resources/Private/Templates/Backend/FormLog/Index.html#L8
Tested with TYPO3 11.5.16 (+ EXT:forms 11.5.16) and PHP 8.0
Files
typo3-11-vanilla.zip (95.7 KB) typo3-11-vanilla.zip | Benedikt Imminger, 2022-10-12 15:10 |
Updated by Benedikt Imminger about 2 years ago
- Related to Bug #98152: PHP Warning: file_exists(): open_basedir restriction in effect. added
Updated by Benni Mack about 2 years ago
- Status changed from New to Needs Feedback
Hey Benedikt,
here is my setup:- freshly installed 11.5.16 (classic mode)
- EXT:form and EXT:form_log installed
- php.ini (PHP 8.1) with open_basedir set to "/Users/benni/Sites/"
- LocalConfiguration.php with BE/debug=true (false does not care here), and versionNumberInFilename=true, display_errors=1
I even removed EXT:form/Resources/Public/Css/form.css
I do get a browser log that the css cannot be found, but I do not get a form warning. What is your "versionNumberInFileName" setting?
Updated by Benni Mack about 2 years ago
- Related to Bug #98330: PHP warning log with EXT-syntax using asset vh in BE added
Updated by Benedikt Imminger about 2 years ago
- File typo3-11-vanilla.zip typo3-11-vanilla.zip added
Hello Benni,
thank you for investigating this issue.
I setup a clean Composer installation with DDEV, PHP 8.1 and TYPO3 11.5.16 + EXT:form. LocalConfiguration contains your suggested settings.
open_basedir is set to "/var/www/html:/usr/local/bin/composer:/home:/tmp:/mnt" (see .ddev/php/php.ini in attached file)
Still getting an error in log module after opening the form module:
Core: Error handler (BE): PHP Warning: file_exists(): open_basedir restriction in effect. File(/typo3/sysext/form/Resources/Public/Css/form.css) is not within the allowed path(s): (/var/www/html:/usr/local/bin/composer:/home:/tmp:/mnt) in /var/www/html/public/typo3/sysext/core/Classes/Utility/GeneralUtility.php line 2317
This warning occurs when versionNumberInFileName is true or false (in the attached file it's currently FALSE).
The DDEV/Composer files are attached to the ticket. I hope this helps to recreate the error
Updated by Arne Bracht about 2 years ago
Hi,
same too:
Core: Error handler (BE): PHP Warning: file_exists(): open_basedir restriction in effect. File(/typo3/sysext/form/Resources/Public/Css/form.css) is not within the allowed path(s): (/home/users/internet/www:/home/users/ja-internet/files:/home/users/internet/tmp:/usr/bin/) in /home/users/internet/www/tools/_t3src/11/typo3_src-11.5.17/typo3/sysext/core/Classes/Utility/GeneralUtility.php line 2317
EXT:form/Resources/Public/Css/form.css will be loaded bei Chrome.
- Upgare from 10.5 to 11.5.17 (classic mode)
- EXT:form installed
- php.ini (PHP 7.4) with open_basedir set to "/home/users/internet/www"
- LocalConfiguration.php with BE/debug=false, and versionNumberInFilename=false, display_errors=0
If Preset Configuration Debug is true the error ist still not there.
Updated by J. Peter M. Schuler over 1 year ago
I ran into the same log entries today in a 11.5.24 on PHP 7.4 as mentioned here and in #98330 for other extensions - I see two important points:
A) The value of open_basedir is irrelevant¶
For some reason the check is done for /typo3/sysext/...
or /typo3conf/ext/...
paths, so basically a frontend url path segment and not a local file prefixed with Environment::getPublicPath()
.
So the check in itself should not be done in that way because either it should not be done with file_exists
as it is a frontend path, or the prefix needs to be in place.
B) Why is the warning not supressed?¶
L2158 is a file_exists
in a TRY block with pokemon exception handling for exceptions
try { $fileExists = file_exists($path); } catch (\Throwable $e) { $fileExists = false; }
However it raises a WARNING and thus won't be catched would it? So the behaviour is undesirable (as in: drop the WARNING please) but still the WARNING is according to code isn't it?
(will look into the actual extension call stack as soon as I get time to identify the reason why a wrong call is done as mentioned in (A))
Updated by Arne Bracht over 1 year ago
TYPO3 11.5.28
PHP 8.1.20
Don't know if this is the same, but in news_administration -> default Template:
<f:asset.css identifier="news_administration" href="EXT:news_administration/Resources/Public/Css/Backend/administration.css" />
CSS is loaded:
Protocol: PHP Warning: file_exists(): open_basedir restriction in effect. File(/typo3conf/ext/news_administration/Resources/Public/Css/Backend/administration.css) is not within the allowed path(s).
I think <f:asset> is not working as it should.
Updated by Garvin Hicking about 1 year ago
- Related to Bug #101921: open_basedir restriction in effect. File(/typo3/sysext/form/Resources/Public/Css/form.css) is not within the allowed added
Updated by Alexander Schnitzler about 1 year ago
B) Why is the warning not supressed?¶
L2158 is a
file_exists
in a TRY block with pokemon exception handling for exceptions[...]
However it raises a WARNING and thus won't be catched would it? So the behaviour is undesirable (as in: drop the WARNING please) but still the WARNING is according to code isn't it?
The behaviour depends on SYS.exceptionalErrors. If you want TYPO3 to convert Warnings to Exceptions, the try..catch block does make sense and you simply ignore the issue. That's funny because if you want to have less issues being converted to exceptions, you get the undesired effect of a flooded backend log because warnings are logged there.
Updated by J. Peter M. Schuler about 1 year ago
That's funny because if you want to have less issues being converted to exceptions, you get the undesired effect of a flooded backend log because warnings are logged there.
That's why I wondered. And having warnings as warnings is/should probably be default.
Updated by Gerrit Code Review 10 months ago
- Status changed from Needs Feedback to Under Review
Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82635
Updated by Gerrit Code Review 10 months ago
Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82635
Updated by Gerrit Code Review 10 months ago
Patch set 3 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82635
Updated by Gerrit Code Review 10 months ago
Patch set 4 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82635
Updated by Gerrit Code Review 10 months ago
Patch set 5 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82635
Updated by Peter Kraume 10 months ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 6d3e4e458622442341852fe33325ef5d5be60359.
Updated by Gerrit Code Review 10 months ago
- Status changed from Resolved to Under Review
Patch set 1 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82616
Updated by Gerrit Code Review 10 months ago
Patch set 2 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82616
Updated by Gerrit Code Review 10 months ago
Patch set 1 for branch 11.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82617
Updated by Gerrit Code Review 10 months ago
Patch set 2 for branch 11.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82617
Updated by Gerrit Code Review 10 months ago
Patch set 3 for branch 11.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82617
Updated by Peter Kraume 10 months ago
- Status changed from Under Review to Resolved
Applied in changeset b305873ff2c741773a4d383bf3620d7e609ee8b4.
Updated by Peter Kraume 10 months ago
- Related to Task #102999: Remove obsolete method resolveResourcePaths() from EXT:form added