Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Issue #6497 - Replace the Alias checkers with new implementation. (Jetty-9.4) #6540
Issue #6497 - Replace the Alias checkers with new implementation. (Jetty-9.4) #6540
Changes from all commits
a1bb8f3
32ae130
be8c6ac
7c0c3c9
1858153
ad85c40
b916269
6909476
68d93fb
a7639bc
32bff77
bf078be
27d8069
6e66604
b1fe449
57741c0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Why calling
toAbsolutePath()
? Isn't just a single/
?Is it because of Windows? If so, needs a comment.
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 won't do what you expect on Windows.
If you are running from a Windows Share for example, take
\\machine\sharename\jetty
your code will result in a Path that is no longer in the share location.Is that what you want?
The Path has a FileSystem object associated with it, you can ask for its root, or even for all roots that the FileSystem layer supports.
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.
Why is this check here? Should it not be in the
SymlinkAllowedResourceAliasChecker
subclass?I mean that seems weird that this base class does a bit of symlink but not all... Can't all symlink handling and configuration fields be pushed to the subclass?
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 different check to what is done in the subclass, the subclass does not even use this logic, it sets
_checkSymlinkTargets
to false.This is an optional check to ensure the target of the symlink is also an allowed resource.
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 don't like this code but I cant think of a better alternative. The call to
toRealPath
requires the file to exist otherwise it throws, but we must check this anyway, because/web-inf
might not exist but/WEB-INF
could exist and so theFiles.exists
call would return 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.
I think we have made a rod for our backs by specifying the protected targets as lowercase
/web-inf
.However, I very much doubt that anybody other than us adds any protected targets, so why don't we just fix this!
We can change our protected targets to use the correct cases and throw an ISE if anybody calls it with any other protected targets (or if the set a protected target that doesn't exist).
Then in doStart we can find the actual
Path
s of all the protected targets (that exist) and replace all this with the logic I prefer... walking up the parent links looking for any path that is sameFile to any of the protected targetsThere 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 don't think its a good idea, we might not think anyone is calling that method, but that's just a guess.
If someone is using it and we change it, then it will expose directories that were previously protected.
Doesn't seem like something we want going into a minor release, especially for
9.4
.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.
Actually maybe we still wouldn't expose it because its still protected by
ContextHander.isProtectedTarget
which is case insensitive.Still doesn't feel like a good idea. Maybe open another issue to consider changing protectedTargets to be case sensitive. We could still change the logic of this later on, but for now it seems like its doing the job of not allowing access to protected targets.
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 think we can check if somebody sets a new protected target that does not exist, so I'm not that worried about breaking any usage of that.
The check that we want to make is that the resource is in the baseResource directory, but is not in any of the protected resource directories. We are trying to do that in a FS independent ways with case insensitive string-starts checks, but they are ultimately just hacks.
If we can precisely identify the
Path
of the base resource and thePath
s of the protected resources. We can then walk the parent linkage of the resource and check that none of it's parents are sameFile as the protected resource and that ultimately one of the parents is sameFile as base resource - we then have an absolutely precise check that does exactly what we want.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.
Maybe we do this only in 10? ... but if we are adding new recommended checkers in 9 and deprecating the existing ones, we may as well add ones that we have 100% confidence in.