[JBoss JIRA] (WFLY-7593) JspTagTestCase fails with security manager
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-7593?page=com.atlassian.jira.plugin.... ]
Ivo Studensky reassigned WFLY-7593:
-----------------------------------
Assignee: Ivo Studensky (was: Jan Tymel)
> JspTagTestCase fails with security manager
> ------------------------------------------
>
> Key: WFLY-7593
> URL: https://issues.jboss.org/browse/WFLY-7593
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.jsp.JspTagTestCase#test*
> {{./integration-tests.sh -DtestLogToFile=false -Dtest=JspTagTestCase -Dsecurity.manager}}
> {code}
> ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /ed26af0c-bc91-49ea-b6c3-196d33e8de5a/index2.jsp: org.apache.jasper.JasperException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/ed26af0c-bc91-49ea-b6c3-196d33e8de5a.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader@a7277ba2")
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346)
> 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.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> 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:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$425.00000000C40C2470.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> 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)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/ed26af0c-bc91-49ea-b6c3-196d33e8de5a.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader@a7277ba2")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Class.getClassLoader(Class.java:442)
> at org.jboss.as.weld.injection.InjectionTargets.createInjectionTarget(InjectionTargets.java:63)
> at org.jboss.as.weld.deployment.WeldClassIntrospector.getInjectionTarget(WeldClassIntrospector.java:90)
> at org.jboss.as.weld.deployment.WeldClassIntrospector.createInstance(WeldClassIntrospector.java:102)
> at org.jboss.as.ee.component.ComponentRegistry.createInstance(ComponentRegistry.java:85)
> at org.jboss.as.web.common.WebInjectionContainer.newInstance(WebInjectionContainer.java:77)
> at org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager.newInstance(UndertowJSPInstanceManager.java:75)
> at org.apache.jsp.index2_jsp._jspx_meth_my_005ftag_005f0(index2_jsp.java:128)
> at org.apache.jsp.index2_jsp._jspService(index2_jsp.java:99)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> ... 48 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFLY-7462) Do not log common CLI failures for Elytron to server log
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7462?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-7462.
------------------------------------
Assignee: Brian Stansberry (was: Darran Lofthouse)
Resolution: Done
> Do not log common CLI failures for Elytron to server log
> --------------------------------------------------------
>
> Key: WFLY-7462
> URL: https://issues.jboss.org/browse/WFLY-7462
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: user_experience
> Fix For: 11.0.0.Alpha1
>
>
> Almost every common CLI command failure from Elytron subsystem is logged as ERROR to server log. For example this means:
> * trying to add duplicate service -> ERROR in server log
> * missing required attribute of any resource attribute in CLI command -> ERROR in server log
> * missing capability -> ERROR in server log
> * ...
> Some reasons why these logs should not be logged to server log:
> * Adding useless messages to server log.
> * This is inconsistent with other subsystems (e.g. PicketBox). It can be confusing.
> These common CLI command failures should be removed from the log, or logged on low level (i.e. DEBUG)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFCORE-2342) CLI can't connect to DC on native port without defined remote protocol
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2342?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2342:
-------------------------------------
Fix Version/s: 3.0.0.Beta7
> CLI can't connect to DC on native port without defined remote protocol
> ----------------------------------------------------------------------
>
> Key: WFCORE-2342
> URL: https://issues.jboss.org/browse/WFCORE-2342
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Remoting, Security
> Reporter: Ken Wills
> Assignee: Ken Wills
> Priority: Blocker
> Labels: cli, regression, remoting, ssl
> Fix For: 3.0.0.Beta7
>
>
> CLI is able to connect to DC to native port (9999) only when protocol _remote_ is specified. It is regression, EAP 7.0.0.GA is able to connect when no protocol is defined or with _remoting_ and _remote_ (maybe some others).
> EAP 7.0.0.GA
> {noformat}
> msimka@msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999
> [domain@127.0.0.1:9999 /] quit
> msimka@msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=remoting://127.0.0.1:9999
> [domain@127.0.0.1:9999 /] quit
> msimka@msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=remote://127.0.0.1:9999
> [domain@127.0.0.1:9999 /] quit
> {noformat}
> EAP 7.1.0.DR12
> {noformat}
> msimka@msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999
> Failed to connect to the controller: Unable to negotiate SSL connection with controller at 127.0.0.1:9999
> msimka@msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=remoting://127.0.0.1:9999
> Failed to connect to the controller: Unable to negotiate SSL connection with controller at 127.0.0.1:9999
> msimka@msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=remote://127.0.0.1:9999
> [domain@127.0.0.1:9999 /] quit
> {noformat}
> Stacktrace from attached jboss-cli.log
> {noformat}
> 15:46:26,184 TRACE [org.jboss.remoting.remote.connection] Connection error detail: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:156)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
> at org.xnio.ssl.JsseStreamConduit.performIO(JsseStreamConduit.java:1364)
> at org.xnio.ssl.JsseStreamConduit.read(JsseStreamConduit.java:991)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:123)
> at org.jboss.remoting3.remote.MessageReader.getMessage(MessageReader.java:131)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:165)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:160)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:446)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFCORE-37) Batching logging profile creation CLI commands can cause errors
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-37?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFCORE-37:
--------------------------------
Workaround Description:
Combine command #3 and #4:
{noformat}
/subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add(handlers=[myHandler])
{noformat}
was:
Combine command #3 and #4:
{noformat}
/subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add(handlers=[handler=myHandler])
{noformat}
> Batching logging profile creation CLI commands can cause errors
> ---------------------------------------------------------------
>
> Key: WFCORE-37
> URL: https://issues.jboss.org/browse/WFCORE-37
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Kyle Lape
> Assignee: James Perkins
>
> Given these set of commands:
> {noformat}
> /subsystem=logging/logging-profile=myLoggingProfile:add
> /subsystem=logging/logging-profile=myLoggingProfile/file-handler=myHandler:add(level=ALL,file={"relative-to" => "jboss.server.log.dir","path" => "myapp.log"})
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add-handler(name=myHandler)
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:change-root-log-level(level=INFO)
> {noformat}
> If I run those in a batch, I get an error:
> {noformat}13:32:52,478 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("add-handler") failed - address: ([
> ("subsystem" => "logging"),
> ("logging-profile" => "myLoggingProfile"),
> ("root-logger" => "ROOT")
> ]) - failure description: "JBAS011536: Handler myHandler is already assigned."
> {noformat}
> If I run each one individually, I get no error.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFLY-7778) Remoting EJB identity propagation does not work with Elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7778?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7778:
-----------------------------
Summary: Remoting EJB identity propagation does not work with Elytron (was: Remoting identity propagation does not work with Elytron)
> Remoting EJB identity propagation does not work with Elytron
> ------------------------------------------------------------
>
> Key: WFLY-7778
> URL: https://issues.jboss.org/browse/WFLY-7778
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
> Labels: elytron-legacy-test-fails
>
> Even througth succesful obtaining LoginContext, identity is not propagated in EJB call.
> Identity is unauthorized on server side.
> *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference.
> Often error message:
> {code:java}
> SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: Server rejected authentication
> DIGEST-MD5: Server rejected authentication]
> at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFLY-6607) Broadcast/Discovery group is possible to create with just a name
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-6607?page=com.atlassian.jira.plugin.... ]
Claudio Miranda commented on WFLY-6607:
---------------------------------------
As the PR is merged, I think this issue may be resolved as done.
> Broadcast/Discovery group is possible to create with just a name
> ----------------------------------------------------------------
>
> Key: WFLY-6607
> URL: https://issues.jboss.org/browse/WFLY-6607
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Web Console
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Chen Maoqian
>
> When defining new broadcast-group in Configuration: Subsystems Subsystem: Messaging - ActiveMQ Messaging Provider: default
> user must define name, at least one connector and then either socket-binding or jgroups-channel-name (not both of them, just one)
> At this moment it's possible to create broadcast group with just a name which is wrong.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (ELY-957) Coverity static analysis: DefaultSingleSignOn.getIdentity() not synchronized
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ELY-957?page=com.atlassian.jira.plugin.sy... ]
Paul Ferraro commented on ELY-957:
----------------------------------
[~mchoma] The purpose of moving the synchronized modifier to an internal synchronized block is not meant to change the behavior - just the signature of the public methods.
I'm not sure what you mean by "future implementations" being safe. The DefaultSingleSignOn and DefaultSingleSignOnEntry objects are an implementation detail of the DefaultSingleSignOnManager implementation. Any implementation of SingleSignOnManager is free to enforce whatever threading constraints it wants/needs.
e.g.
https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
> Coverity static analysis: DefaultSingleSignOn.getIdentity() not synchronized
> ----------------------------------------------------------------------------
>
> Key: ELY-957
> URL: https://issues.jboss.org/browse/ELY-957
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 1.1.0.Beta24
> Reporter: Martin Choma
> Assignee: Paul Ferraro
> Priority: Minor
>
> Coverity static-analysis scan found getter is not synchronized, while setter is.
> {code}
> public SecurityIdentity getIdentity() {
> return this.entry.getCachedIdentity().getSecurityIdentity();
> }
> {code}
> Current implementation is correct because in DefaultSingleSignOnEntry (currently only avalaible implementation of SingleSignOnEntry) cachedIdentity is volatile.
> However other implementations can be wrongly implemented. Once getIdentity() would be marked with synchronize modifier, such problem shouldn't occure.
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=84908...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months