Incorrect file handling for symlinked paths

[verybigelephants]

Describe the bug
dompdf/src/Img/Cache.php method resolve_url tries to validate paths. however, it uses dompdf/src/Helpers.php's build_url method and on line 115 there is this nasty bug $filepath = realpath($ret); where realpath will unwrap any symlink into actual full path, (like when you symlink a mounted extra disk space from /mnt/ to hold all of your images for example)

then, the resolve_url continues to check the rules in

                foreach ($allowed_protocols[$protocol]["rules"] as $rule) {
                    [$result, $message] = $rule($full_url);
                    if (!$result) {
                        throw new ImageException("Error loading $url: $message", E_WARNING);
                    }
                }

and then of course it's throwing an error message, saying
The file could not be found under the paths specified by Options::chroot.
because the unwrapped symlink may be outside of the website's allowed directory, even though it is fully valid path accessible by the rest of the appliation

To Reproduce
Steps to reproduce the behavior:

• Laravel and package version
  "barryvdh/laravel-dompdf": "^2.0",
• Input HTML/CSS
  "trying to render any image behind a symlink" like <img src="/home/www/somedomain.com/public/media/id/something.jpg"/> where /home/www/somedomain.com/public/media is a symlink to a directory outside /home/www/somedomain.com/

Expected behavior
not unwrapping the symlink into real path, thus failing the rule for allowed directories

[bsweeney]

I'm not sure I would classify this as unexpected behavior, though it may be undesirable. To make it possible to not resolve symlinks we'd have to write our own path parsing logic.

You can work around the problem by adding the target of the symlink to your chroot (it's a collection of paths). The other option would be to replace the validation logic for the file:// scheme.

[verybigelephants]

Hi, thanks for the reply!

I have teporarily modified vendor src files to not unwrap symlinks with the realpath, as i definitely do not think that you should change chroot for every symlinked subirectory that's inside your app. That would just break the whole concept of symlinks in nix systems.

If a directory is present within the chroot it should be valid, no matter wheter it's a real directory or symlink

[bsweeney]

Feel free to submit a PR if you have a better method for resolving a path for chroot checks.