New +s directory permissions lead to failing is_file() in template path resolution
When updating to 8.7.4 via install tool, the subdirectories in typo3_src-8.7.4 have these permission: "drwxr-sr-x". In older releases, the permissions were these: "drwxr-xr-x".
When working with directories with +s permissions, PHP function is_file() always returns false (see http://php.net/manual/de/function.is-file.php#107403). This could be an issue in several places in the core.
Example: I ran in the issue, that my partial root path was not recognized. After digging in, I found in /typo3_src/vendor/typo3fluid/fluid/src/View/TemplatePaths.php in resolveFileInPaths(), that the presence of template files is checked with is_file(). That means, that template resolution is not working anymore for example.
- Changing the funtions from is_file() to file_exists() resolves the issue.
- Changing directory permissions from +s to +x also resolves the issue.
I suggest, changing back the permissions in the distributed tarballs back to +x if there was no explicit reason why to have it changed to +s in the future.
(Possibly regression, and category security)
#2 Updated by Claus Due almost 2 years ago
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?
#3 Updated by Gregor Favre almost 2 years ago
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.
#4 Updated by Claus Due almost 2 years ago
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).
#5 Updated by Gregor Favre almost 2 years ago
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.
#6 Updated by Gregor Favre almost 2 years ago
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.
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.
#9 Updated by Gregor Favre 4 months ago
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.