Chmod permission handling for user profile folder

[martipoe]

The folder for user profile images in fileadmin/user_upload/oauth is not created with the TYPO3 permission mask. As a result, rsync or file creation may fail due to insufficient permissions.

Expected behaviour: The folder "oauth" is created with the chmod permissions from SYS/folderCreateMask.

[maikschneider]

The profile folder is created via the system function GeneralUtility::mkdir_deep() which uses the configured folderCreateMask: Are you sure the created folder permission differs from $GLOBALS['TYPO3_CONF_VARS']['SYS']['folderCreateMask'] (default 0755)?

[martipoe]

The default folderCreateMask in TYPO3 is 2775: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Configuration/Typo3ConfVars/SYS.html#typo3ConfVars_sys_folderCreateMask

"2" is the setgid bit - a folder created with such permissions has its contents writable by group members, which is the desired behaviour.

GeneralUtility attempts to read this variable and otherwise falls back to 0755: https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Utility/GeneralUtility.php#L1511 $targetPermissions = (string)($GLOBALS['TYPO3_CONF_VARS']['SYS']['folderCreateMask'] ?? '0755');

This means GeneralUtility cannot read $GLOBALS['TYPO3_CONF_VARS']['SYS']['folderCreateMask'] of its instance?

Checked with v11 as well as v12, same behaviour.

Hint: The variables are not explicitly defined in settings.php (v12) or LocalConfiguration.php (v11) - if they were, GeneralUtility might actually read them and create directories with the proper mask (test required). Still, I would like to understand why TYPO3 hardcodes different fallbacks for the same variable.

[maikschneider]

Oh yes, the ?? fallback is chosen - this means it is not defined ~ it's not explicit set in the LocalConfiguration.php (v11) or settings.php. Let's have a discussion about the concrete project where it is missing.