The getLocalPath($uri) method on Drupal\Core\StreamWrapper\LocalStream does not handle symlinks correctly, which may cause failed `public://$somepath` (and other) resolutions.
Steps to reproduce:
$HOME/mine, containing $HOME/mine/some.file$D8, symlink that directory under the public files directory:cd $D8
cd sites/default/files
ln -s $HOME/mine
ls $D8/sites/default/files/mine works normally and shows some.file$public = \Drupal::get('@stream_wrapper.public')->realpath();
$path = "$public/mine/some.file";
var_dump(is_readable($path)); // TRUE
$path = 'public://mine/some.file';
var_dump(is_readable($path); // FALSE
What happens in getLocalPath() is that it tries to outsmart the file system by double checking real absolute paths, which does not work in the presence of symlinks. Summarizing :
$realpath = realpath($path); return the full path of the target
$directory = realpath($this->getDirectoryPath); returns the full path above the symlinkif (strpos($realpath, $directory) !== 0) return FALSE; assumes full path below symlink contains full path above, which is not true if the symlink is outside the directory.This check is probably here for a safety reason, however history stops at commit b27e906, for issue #1475020: Convert stream_wrappers.inc to PSR-0 → , so this behavior is earlier (03/2012).
Postponed: needs info
11.0 🔥
file system
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I reviewed this issue as part of Bug Smash Initiative.
I did not try to reproduce this locally. It looks like the code is almost identical to when the issue was posted.
Unfortunately there is no context to that change to inform whether it is intended behavior for security reasons.
It would be helpful to have an automated test to prove the bug exists.
I'm changing to PMNI to get feedback from the OP and see if it is still occurring.