SymlinkAllowedResourceAliasChecker is initialized after checkAlias is called resulting that access to resource is denied

[jlindman]

Jetty version(s)

11.0.8-11.0.11

Java version/vendor (use: java -version)

openjdk version "17.0.3" 2022-04-19

OS type/version

Ubuntu 20.04.4 LTS

Description

I have a JAX-WS application that reads the configuration file /WEB-INF/sun-jaxws.xml.

When the WEB-INF directory is inside a directory that is a symlink the sun-jaxws.xml file cannot be retrieved since is not allowed because the WEB-INF directory is protected.

This results in the following error:

SEVERE: WSSERVLET11: failed to parse runtime descriptor: jakarta.xml.ws.WebServiceException: Runtime descriptor "/WEB-INF/sun-jaxws.xml" is missing

Adding below works with Jetty 11.0.7 (where webapp is a symlink):

ContextHandler linkHandler = new ContextHandler();
linkHandler.setResourceBase("webapp");
webapp.addAliasCheck(new SymlinkAllowedResourceAliasChecker(linkHandler));

However, with Jetty 11.0.8 this stopped working. It looks like the initialization of the AllowedResourceAliasChecker is now done too late(?). The resource base seems to be null when aliasCheck is made.

With 11.0.8 the resource base is null for the SymlinkAllowedResourceAliasChecker objects (which was not the case for 11.0.7).

In ContentHandler.checkAlias():1967

getAliasChecks() ->
 result = {Collections$UnmodifiableRandomAccessList@7090}  size = 2
  0 = {SymlinkAllowedResourceAliasChecker@3192} "SymlinkAllowedResourceAliasChecker@54f6b629{base=null,protected=[/META-INF, /WEB-INF]}"
  1 = {SymlinkAllowedResourceAliasChecker@3827} "SymlinkAllowedResourceAliasChecker@4bc9ca97{base=null,protected=[]}"

Stacktrace:

checkAlias:1967, ContextHandler (org.eclipse.jetty.server.handler)
getResource:1941, ContextHandler (org.eclipse.jetty.server.handler)
getResource:411, WebAppContext (org.eclipse.jetty.webapp)
getResource:1445, WebAppContext$Context (org.eclipse.jetty.webapp)
parseAdaptersAndCreateDelegate:93, WSServletContextListener (com.sun.xml.ws.transport.http.servlet)
contextInitialized:122, WSServletContextListener (com.sun.xml.ws.transport.http.servlet)
callContextInitialized:1040, ContextHandler (org.eclipse.jetty.server.handler)
callContextInitialized:624, ServletContextHandler (org.eclipse.jetty.servlet)
contextInitialized:977, ContextHandler (org.eclipse.jetty.server.handler)
initialize:705, ServletHandler (org.eclipse.jetty.servlet)
startContext:392, ServletContextHandler (org.eclipse.jetty.servlet)
startContext:1305, WebAppContext (org.eclipse.jetty.webapp)
doStart:896, ContextHandler (org.eclipse.jetty.server.handler)
doStart:306, ServletContextHandler (org.eclipse.jetty.servlet)
doStart:533, WebAppContext (org.eclipse.jetty.webapp)
start:93, AbstractLifeCycle (org.eclipse.jetty.util.component)
start:171, ContainerLifeCycle (org.eclipse.jetty.util.component)
start:469, Server (org.eclipse.jetty.server)
doStart:114, ContainerLifeCycle (org.eclipse.jetty.util.component)
doStart:89, AbstractHandler (org.eclipse.jetty.server.handler)
doStart:414, Server (org.eclipse.jetty.server)
start:93, AbstractLifeCycle (org.eclipse.jetty.util.component)
main:26, TestServer

This can possibly be related to #8259

Here is a sample maven application that reproduces the behavior: symlinktest.tar.gz

[lachlan-roberts]

@jlindman thanks for the reproducer.

I think what you are doing by adding an alias checker for the link handler onto your webapp is wrong.
webapp.addAliasCheck(new SymlinkAllowedResourceAliasChecker(linkHandler));
Why are you creating the link handler?

---

This is related to the recent rework of the alias checkers into AllowedResourceAliasChecker. I can see two reasons in Jetty why this isn't currently working for this use case:

1. The AllowedResourceAliasChecker now waits until lifeCycleStarted before it extracts the base resource, as the base resource can still change until ContextHandler is fully started. And this code is getting a resource before the ContextHandler is fully started.
2. The resource it is trying to access is /WEB-INF/sun-jaxws.xml and SymlinkAllowedResourceAliasChecker would normally see this to be in a protected directory (if the protected target /WEB-INF is defined) and therefore does not allow the alias.

I would have expected the alias checkers would not be applied for explicit calls to the getResource api and only needed through default servlet and resource handler. So we will need to review this.

[lachlan-roberts]

There are fixes for this merged with PR #8315, this will be available in a 10.0.12/11.0.12 release.