-
Notifications
You must be signed in to change notification settings - Fork 422
Handle symlinking edge cases #1660
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| absFileName, err := filepath.EvalSymlinks(o.fileName) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("worker filename is invalid %q: %w", o.fileName, err) | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it 👍 explicitly checking if a worker exists is something I actually wanted to do for a long time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or wait, evalSymlinks will just evaluate symlinks. In that case it would also be nice to error right away if there's no file there. Can also be done in another PR though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it errors if the file doesn't exist (I had to update a failing test -- haven't pushed the commit yet)
| //If we do not have a resolved document root, then we cannot resolve the symlink of our cwd because it may | ||
| //resolve to a different directory than the one we are currently in. | ||
| //This is especially important if there are workers running. | ||
| documentRootOption = frankenphp.WithRequestDocumentRoot(documentRoot, false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not checking for symlinks here seems like it might break some setups. Definitely would be nice to test all the edge cases somehow (should be possible with caddy_tests?).
Tbh though, I don't know what the current edge cases with symlinks are
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m pretty sure we don’t want to evaluate symlinks here. In the case where a document root was expressly given (such as prod setups), we will never even enter this branch. In the case where a document root isn’t given, we need to be compatible with how we resolve workers. There is an edge case here that I didn’t cover, and I’m working out how to handle it: chained symlinks.
I suspect I’ll have to go back to the drawing board.
|
do the edge cases only affect workers, not regular php requests? |
|
@henderkes yes, only workers. I should have a nice test suite this weekend. Manually testing this is annoying. |
|
@withinboredom should I pick this up or do you have something stashed away to commit? |
|
TBH, I forgot this existed. If you want to take a gander, go for it! |
|
In adding a test manually after AI generated the bunch, of course the manually generated one errors. Edge case when using relative worker scripts: localhost
php {
root /path/to/symlink
worker index.php
} |
| // Given frankenphp located in the test folder | ||
| // When I execute `frankenphp php-server --listen localhost:8080 -w index.php` from `public` | ||
| // Then I expect to see the worker script executed successfully | ||
| func TestSymlinkNeighboringWorkerScript(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't you use subtests instead a separated tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll refactor it tomorrow, thanks for the link.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh and Happy New Year!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy new year!! And thanks.
| @@ -0,0 +1 @@ | |||
| test No newline at end of file | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| test | |
| test | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a symlink, not a text file. I don't think we should be changing the content
Co-authored-by: Kévin Dunglas <[email protected]> Signed-off-by: Marc <[email protected]>
Co-authored-by: Kévin Dunglas <[email protected]> Signed-off-by: Marc <[email protected]>
Co-authored-by: Kévin Dunglas <[email protected]> Signed-off-by: Marc <[email protected]>
This one is interesting — though I’m not sure the best way to provide a test. I will have to look into maybe an integration test because it is a careful dance between how we resolve paths in the Caddy module vs. workers. I looked into making a proper change (literally using the same logic everywhere), but I think it is best to wait until #1646 is merged.
But anyway, this change deals with some interesting edge cases. I will use gherkin to describe them:
Trying to write that out in regular English would be more complex IMHO.
These scenarios should all pass now with this PR.