TYPO3 Core

However, in resolveFileInPaths() using is_file() probably is also wrong, because of it checking on i.e. "Footer.html" and "Footer". Last one is a directory and exists, but I think is_file() returns false on a directory?

However, in resolveFileInPaths() using is_file() probably is also wrong, because of it checking on i.e. "Footer.html" and "Footer". Last one is a directory and exists, but I think is_file() returns false on a directory?

No - one is a file with a format as extension, the other is a file check without extension. The method finds files and must never return folder names.

Apart from that I can't say exactly what the reason for +s is but maybe that's caused by your httpd's umask rather than TYPO3 itself?

I created a test PHP script which extracts the TYPO3 core like in the UpdateService of the install tool:

$unpackCommand = 'tar xf ' . escapeshellarg('typo3_src-8.7.6.tar.gz') . ' 2>&1';
exec($unpackCommand);

When i run this command in my test script, all permissions are set correctly, hence there should be no umask problem.

Also tried on a server of an other hosting provider, and also there suddenly after updating over the install tool, permissions are set with +s instead of +x.

I think something has changed in the updater process of the install tool, and now is_file() usages are breaking here and there.

If you tested that script on CLI it may still not have the same umask as the httpd user. You'd have to run it through a php script your httpd serves to confirm the umask. I could spot nothing in the CoreUpdateService that would set +s so I have to assume this is your httpd, possibly inherited from parent dir(s).

I tested the unpack command directly over httpd, and the persmissions are then set correctly (drwxr-xr-x). Only when I unpack the sources over the install tool, the permissions are set wrong (drwxr-sr-x). I also haven't seen some chmodding in the said service class.

The only difference between my test script and the install tool is, that the latter is called over a symlink (since TYPO3 sources are symlinked). My test script is not symlinked. Will try that later, and post the results.

Update: It also has nothing to do with symlinks. My test script called over a symlink also sets permissions correctly. I don't know where to search anymore now.

However, since I encounter this new behaviour at two different quite large hosting providers, I want to raise the question, whether the problem should not be addressed in TYPO3 itself: I can imagine that other people will encounter that problem too. However it may be seldom that normal users start overloading fluid templates, but when the permissions are set with +s, template overloading unfortunately doesn't work, and it is quite hard for a user to find the reason.

An option would be to introduce a "file and folder" check in the install tool, which checks for correct permissions in the source. This would hinder a user to run the TYPO3 updater and end up with messed-up permissions, which will break core functionality. At least this would give a user a pointer to where the problem is.

Even better would be to have wrong permissions to be autofixed after the update (looping over all subdirectories and setting them +x when they are set +s). I can try to provide such a patch, but beforehand want to know, why we suddenly have thos +s perms. This must come from somewhere and it certainly has its reasons.

Update: it seems that this started happening on web servers running Plesk version 17 and higher, but I can't tell for sure. On two hosts running Plesk 17.5 I have that issue, which can be reproduced. It would be nice if someone could double-check on this.

Hey Gregor - is this still an issue for you? I'm facing some refactoring in precisely the template file resolving logic so it would help me if you've been able to determine:

• if this is indeed a permissions issue (that +s does not transfer +x because a parent won't allow it)
• if it isn't, whether any of the alternative "file exists" and "read folder" methods are able to cut through your use case?

Thanks in advance for any further info you may be able to give ;)

PS: I do not believe that enforcing +x from within TYPO3 is the solution. Rather we should figure out exactly why your sticky situation (pun intended) isn't working right.

Hello Claus

Thanks for getting back to me, I just checked this now on some of my installations. It seems that in Version 9.5, the subdirectories in typo3_src have the permissions reverted to "drwxr-xr-x", so without the "s" bit. That's interesting. Hence, starting with version 9, everything works again like it should. I think this permission issue was introduced somewhen in early 8.x, and in 8.7.24 these "s" permissions are still there.

However I don't know if it is required to fix that in 8.7, so for me it's okay to let it be there, but to make sure it will not get reintroduced in 9.5 :)

Changing the funtions from is_file() to file_exists() in /typo3_src/vendor/typo3fluid/fluid/src/View/TemplatePaths.php in resolveFileInPaths() would resolve that issue in 8.x however.

Since installation of TYPO3 is as default composer-based, the issue with the wrong permissions in the tarball is not a problem anymore. I think we can close that. Thanks!