Bug #105424
closed
Open Basdir SVG Icons
0%
Description
Core: Error handler (BE): PHP Warning: file_exists(): open_basedir restriction in effect. File(/typo3/sysext/install/Resources/Public/Icons/modules/install-manage-settings.svg) is not within the allowed path(s)
Fresh installation TYPO3 13.4.0. The Log is full of this entries.
Problem with the Icons:
install-manage-settings.svg
install-manage-presets.svg
install-manage-features.svg
install-manage-maintainer.svg
install-manage-maintainer.svg
install-extension-settings.svg
But all icons load and are visibel. It's only in the log.
Updated by Garvin Hicking 28 days ago
- Related to Bug #101350: open_basedir restriction in effect added
Updated by Garvin Hicking 28 days ago
- Status changed from New to Closed
Hi!
Thanks for reporting this. This is a (longer) known issue also addressed in #101350
To avoid duplicates I am closing this one, but have related the tickets to each other. The problem is that the TYPO3 core does some checks that do not prefix the site installation path to an open_basedir check as a fallback, before another path variant is tried.
Please note, open_basedir in PHP is a crutch that does not really tighten security in the end, several PHP commands circumvent open_basedir restrictions already. If you have the possibility to disable open_basedir restrictions (often not possible on shared webhosting of course), that would be a good circumvention of the trouble right now. Of course, fixing the actual bug needs to be done despite of this. :-)
Thanks,
Garvin
Updated by Arne Bracht 28 days ago
Oh, i think it is not the same. This here is from Core. Here is it an extension: https://forge.typo3.org/issues/101350
The failure is from GeneralUtility Line 2037
try {
$fileExists = file_exists($path); // @todo: in v13 this should be resolved by using Environment::getPublicPath() only
if ($isFrontend) {
// Frontend should still allow /static/myfile.css - see #98106
// This should happen regardless of the incoming path is absolute or not
$path = self::resolveBackPath(self::dirname(Environment::getCurrentScript()) . '/' . $path);
} elseif (!PathUtility::isAbsolutePath($path)) {
// Backend and non-absolute path
$path = self::resolveBackPath(self::dirname(Environment::getCurrentScript()) . '/' . $path);
}
if ($isFrontend) {
$configValue = (bool)($GLOBALS['TYPO3_CONF_VARS']['FE']['versionNumberInFilename'] ?? false);
} else {
$configValue = (bool)($GLOBALS['TYPO3_CONF_VARS']['BE']['versionNumberInFilename'] ?? false);
}
try {
$fileExists = file_exists($path);
Updated by Garvin Hicking 28 days ago
Hi!
It dosn't matter which URI/file reference is used. The error in both your ticket and the other one lands in GeneralUtility? You quoted the same code like the other ticket also mentions?
Thanks for the quick feedback,
Garvin
Updated by Arne Bracht 28 days ago
Garvin Hicking wrote in #note-4:
Hi!
It dosn't matter which URI/file reference is used. The error in both your ticket and the other one lands in GeneralUtility? You quoted the same code like the other ticket also mentions?
Thanks for the quick feedback,
Garvin
Ok, thanks a lot. For testing purpose only TYPO 13.4.0 I have now underpress the check: $fileExists = @file_exists($path);
Updated by Garvin Hicking 28 days ago
Yes, patching it like that is probably an easy way. For the core however, before executing file_exists we would probably need to add more logic to it that parses the URL first, checks if the location is part of the TYPO3 base dir, and probably detect whether open_basedir is set or not.
Just throwing possible file locations (multiple ones are tried/resolved) at file_exists is the "easy mode" for the file lookup, but open_basedir really does not like that easy mode. ;)