[JBoss JIRA] (JBEE-166) Permission check failures when running with Security Manager enabled
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/JBEE-166?page=com.atlassian.jira.plugin.s... ]
Yeray Borges resolved JBEE-166.
-------------------------------
Fix Version/s: jboss-jaxb-api_2.2_spec-1.0.5.Final
Resolution: Done
> Permission check failures when running with Security Manager enabled
> --------------------------------------------------------------------
>
> Key: JBEE-166
> URL: https://issues.jboss.org/browse/JBEE-166
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-jaxb-api
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Fix For: jboss-jaxb-api_2.2_spec-1.0.5.Final
>
>
> When running with Security Manager enabled there are two failures due to:
> 1. RuntimePermission("getClassLoader"), see the stacktrace:
> {noformat}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {noformat}
> 2. and FilePermission("modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.jbossorg-1.jar", "read"), the stacktrace is as follows:
> {noformat}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "....../jboss-eap/dist/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.jbossorg-1.jar" "read")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
> at java.util.zip.ZipFile.<init>(ZipFile.java:210)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1045)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:292)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I believe these two places are worth enclosing with a privileged block.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFCORE-2235) Intermittent module loading failure in InterdependentDeploymentTestCase
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugi... ]
Jeff Mesnil resolved WFCORE-2235.
---------------------------------
Fix Version/s: 5.0.0.Alpha4
Resolution: Done
> Intermittent module loading failure in InterdependentDeploymentTestCase
> -----------------------------------------------------------------------
>
> Key: WFCORE-2235
> URL: https://issues.jboss.org/browse/WFCORE-2235
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules, Server
> Affects Versions: 4.0.0.Alpha6
> Reporter: Brian Stansberry
> Assignee: Richard Opalka
> Fix For: 5.0.0.Alpha4
>
> Attachments: WFCORE-2235svcdump.txt
>
>
> InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
> The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
> https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore...
> The most notable bit of info in the log is:
> {code}
> 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
> at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
> at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
> at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
> at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
> ... 6 more
> {code}
> The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
> The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10266) [GSS](7.1.z) CodecSessionConfig#findSessionId() can cause an incorrect JSESSIONID response cookie reusing a requested non-existent session id
by Masafumi Miura (JIRA)
Masafumi Miura created WFLY-10266:
-------------------------------------
Summary: [GSS](7.1.z) CodecSessionConfig#findSessionId() can cause an incorrect JSESSIONID response cookie reusing a requested non-existent session id
Key: WFLY-10266
URL: https://issues.jboss.org/browse/WFLY-10266
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 12.0.0.Final
Reporter: Masafumi Miura
Assignee: Stuart Douglas
Fix For: 13.0.0.Beta1
When a client sends a request with a non-existent session id to a web application calling "HttpServletRequest#getRequestedSessionId()" or "HttpServletRequest#isRequestedSessionIdValid()", WildFly responds with an incorrect JSESSIONID response cookie reusing the requested non-existent session id even though a new session id is internally generated.
{code:title=a simple reproducer}
<%
out.println("request.getRequestedSessionId() = " + request.getRequestedSessionId());
out.println("request.isRequestedSessionIdValid() = " + request.isRequestedSessionIdValid());
out.println("session.getId() = " + session.getId());
%>
{code}
The following is an example result. WildFly should not respond with "Set-Cookie: JSESSIONID=test.node1" but should respond with a new session id like "Set-Cookie: JSESSIONID=brzJWBXpBnUZelcwnI9HCEbw9X6d0oQ5PypfiwML.node1" in this case.
{code}
$ curl -v http://node1:8080/test/example.jsp -H "Cookie: JSESSIONID=test"
...
> GET /test/example.jsp HTTP/1.1
> User-Agent: curl/7.29.0
> Host: node1:8080
> Accept: */*
> Cookie: JSESSIONID=test
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< X-Powered-By: JSP/2.3
< Set-Cookie: JSESSIONID=test.node1; path=/test
< Content-Type: text/html;charset=ISO-8859-1
< Content-Length: 143
< Date: Wed, 18 Apr 2018 17:11:58 GMT
<
request.getRequestedSessionId() = test
request.isRequestedSessionIdValid() = false
session.getId() = brzJWBXpBnUZelcwnI9HCEbw9X6d0oQ5PypfiwML
{code}
WildFly "CodecSessionConfig#findSessionId()" is invoked from Undertow "HttpServletRequestImpl#getRequestedSessionId() and isRequestedSessionIdValid()" to obtain the request session id.
In "CodecSessionConfig#findSessionId()", WildFly checks if the reencoded session id is changed or not (= if an instance-id /jvmRoute information is changed or not), then invokes "this.config.setSessionId(exchange, reencodedSessionId)" to reset session id. Encoding a non-existent session always results in the different reencoded session id, therefore "this.config.setSessionId(exchange, reencodedSessionId)" is always invoked and this issue happens in this scenario.
{code:title=Undertow - servlet/src/main/java/io/undertow/servlet/spec/HttpServletRequestImpl.java}
349 @Override
350 public String getRequestedSessionId() {
351 SessionConfig config = originalServletContext.getSessionConfig();
352 if(config instanceof ServletContextImpl.ServletContextSessionConfig) {
353 return ((ServletContextImpl.ServletContextSessionConfig)config).getDelegate().findSessionId(exchange);
354 }
355 return config.findSessionId(exchange);
356 }
:
421 @Override
422 public boolean isRequestedSessionIdValid() {
423 HttpSessionImpl session = servletContext.getSession(originalServletContext, exchange, false);
424 if(session == null) {
425 return false;
426 }
427 if(session.isInvalid()) {
428 return false;
429 }
430 return session.getId().equals(getRequestedSessionId());
431 }
{code}
{code:title=WildFly - undertow/src/main/java/org/wildfly/extension/undertow/session/CodecSessionConfig.java}
54 @Override
55 public String findSessionId(HttpServerExchange exchange) {
56 String encodedSessionId = this.config.findSessionId(exchange);
57 if (encodedSessionId == null) return null;
58 String sessionId = this.codec.decode(encodedSessionId);
59 // Check if the encoding for this session has changed
60 String reencodedSessionId = this.codec.encode(sessionId);
61 if (!reencodedSessionId.equals(encodedSessionId)) {
62 this.config.setSessionId(exchange, reencodedSessionId);
63 }
64 return sessionId;
65 }
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10265) UT005028 ClosedChannelException in load balancer
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10265?page=com.atlassian.jira.plugin... ]
Radoslav Husar reassigned WFLY-10265:
-------------------------------------
Component/s: Web (Undertow)
(was: Clustering)
Assignee: Stuart Douglas (was: Paul Ferraro)
> UT005028 ClosedChannelException in load balancer
> ------------------------------------------------
>
> Key: WFLY-10265
> URL: https://issues.jboss.org/browse/WFLY-10265
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Final
> Environment: Windows 10 or Windows Server 2016
> Reporter: Robert Van Loenhout
> Assignee: Stuart Douglas
>
> I have installed Keycloak 3.4.3. I use a configuration with a load balancer with 2 (local) server instances.
> On a Linux machine (CentOS 7) I do not see any errors in the load balancer log. However on Windows (10 and 2016) I see the following errors in the load balancer log:
> {code}
> 2018-04-18 17:35:48,367 ERROR [io.undertow.proxy] (default I/O-4) UT005028: Proxy request to /auth/resources/3.4.3.final/admin/keycloak/templates/kc-paging.html failed: java.nio.channels.ClosedChannelException
> at io.undertow.client.ajp.AjpClientConnection$3.handleEvent(AjpClientConnection.java:122)
> at io.undertow.client.ajp.AjpClientConnection$3.handleEvent(AjpClientConnection.java:109)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:1045)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:959)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.terminated(ReadReadyHandler.java:71)
> at org.xnio.nio.NioSocketConduit.readTerminated(NioSocketConduit.java:332)
> at org.xnio.nio.NioSocketStreamConnection.notifyReadClosed(NioSocketStreamConnection.java:148)
> at org.xnio.Connection.close(Connection.java:139)
> at org.xnio.IoUtils.safeClose(IoUtils.java:152)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.close(AbstractFramedChannel.java:793)
> at io.undertow.client.ajp.AjpClientConnection.close(AjpClientConnection.java:304)
> at org.xnio.IoUtils.safeClose(IoUtils.java:152)
> at io.undertow.server.handlers.proxy.ProxyHandler$IoExceptionHandler.handleException(ProxyHandler.java:770)
> at org.xnio.ChannelListeners.invokeChannelExceptionHandler(ChannelListeners.java:126)
> at io.undertow.util.Transfer$TransferListener.handleEvent(Transfer.java:193)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.channels.DetachableStreamSourceChannel$SetterDelegatingListener.handleEvent(DetachableStreamSourceChannel.java:231)
> at io.undertow.channels.DetachableStreamSourceChannel$SetterDelegatingListener.handleEvent(DetachableStreamSourceChannel.java:218)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSourceChannel$1.run(AbstractFramedStreamSourceChannel.java:282)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$3.run(AbstractFramedChannel.java:231)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> {code}
> The application does actually seem to work fine.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years