wrong Filepermissions, on some (!) machines, V7.1.3

[Eumolp]

This bug seems still to bite me. But not in gerneral:
On my development machine (same Typo3 V12.4. php8.1) everything is OK, but installing on a live-Server this issue drives you mad.

I am not the best developer, but I checked:

• GeneralUtility::writeFile() does not explicitly set a right
• the behavior is platform-specific and unstable (locally it works, live not)

When writing temporary JS files in AssetService.php (e.g. $tmpFile), the file permissions are set to 0600 depending on the system. This prevents loading in the FE if the umask is restrictive.
Suggestion: After GeneralUtility::writeFile() explicitly set @chmod($tmpFile, 0644).

Classes/Service/AssetService.php:
781 > GeneralUtility::writeFile($tmpFile, $contents, true);
782 > + @chmod($tmpFile, 0644);
783 > if (@rename($tmpFile, $file) === false) {

So far the bug only occures with JavaScript files, not CSS. But this is not really tested.

Originally posted by @Eumolp in #1944

[NamelessCoder]

VHS relies on core's routines to set the appropriate file permissions in order to respect settings that deal with ownership, permissions, temp directory, etc. - so, the solution will not be to dispatch calls to chmod within VHS code. If your setup is affected by this issue it is likely to affect other parts of TYPO3 and third party code (see reasons below) and in order to fix it, you must configure the system correctly or change your paths structure as necessary.

Here is the expected execution logic:

• GU::tmpnam is called to generate a temporary file path+name.
• GU::writeFile is called, asking to write that temp file.
• GU::writeFile internally calls GU::fixPermissions to adjust file permissions according to settings.
• GU::fixPermissions internally calls GU::isAllowedAbsPath and only if this returns true does it attempt to adjust permissions.
• The temporary file is renamed/moved to the final location.

See:

• https://github.com/TYPO3/typo3/blob/v12.4.32/typo3/sysext/core/Classes/Utility/GeneralUtility.php#L1636
• https://github.com/TYPO3/typo3/blob/v12.4.32/typo3/sysext/core/Classes/Utility/GeneralUtility.php#L2664
• https://github.com/TYPO3/typo3/blob/v12.4.32/typo3/sysext/core/Classes/Utility/PathUtility.php#L458

The problem historically was that tmpnam was called outside of GU and generated a path that was not within the TYPO3 project path. This causes GU::isAllowedAbsPath to return false which causes GU::fixPermissions to not enter the code block that actually adjusts the permissions, instead silently ignoring that problem and allowing execution to continue. That then causes the final file to not have the correct permissions (no permissions were changed by GU::fixPermissions so the file is owned by the default user and permissions are whichever default umask is configured in PHP/httpd).

Which means that when this goes wrong, it's because the path of the temporary file created with GU::tmpnam and GU::writeFile is outside of the TYPO3 project directory in a path that is not explicitly configured as a "safe" absolute path.

One solution if your files must reside outside the TYPO3 project root is to add whichever paths that are outside the project root, to the setting BE.lockRootPath - for example if they are in a symlink target outside the project folder, which is a common use case for systems that use tools like Deployer which writes the entire deployment artifact and then links it, creating symlinks to the files/folders that are not part of deployed code (fileadmin, var, etc.).

// ext_localconf.php, additional.php or directly in configuration.php
$GLOBALS['TYPO3_CONF_VARS']['BE']['lockRootPath'] = ['/my/path1', '/my/path2'];

This causes PathUtility::isAllowedAdditionalPath to return true indicating a safe path, which in turn makes GU::fixPermissions enter the code block that adjusts permissions.