[JBoss JIRA] (ELY-1164) Wildfly Elytron Tool, credential-store command doesn't support redirection (<, <<) when multiple options are missing which show prompts.
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-1164:
---------------------------------
Summary: Wildfly Elytron Tool, credential-store command doesn't support redirection (<, <<) when multiple options are missing which show prompts.
Key: ELY-1164
URL: https://issues.jboss.org/browse/ELY-1164
Project: WildFly Elytron
Issue Type: Bug
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Priority: Blocker
Wildfly Elytron Tool, credential-store command doesn't support redirection (<, <<) when multiple options are missing which show prompts.
User omit --password and --secret options and then get two (four: there is confirmation) prompts but user isn't able to redirect data to second one.
Expected behaviour is that it must work.
*How to reproduce*
{code}
java -jar wildfly-elytron-tool.jar credential-store --add secret_alias --create -l cs001.jceks --summary << EOF
pass123
pass123
secret_value
secret_value
EOF
{code}
*has this output:*
{code}
Exception encountered executing the command:
java.lang.Exception: java.io.IOException: Stream closed
at org.wildfly.security.tool.Command.prompt(Command.java:115)
at org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:184)
at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:75)
Caused by: java.io.IOException: Stream closed
at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:170)
at java.io.BufferedInputStream.read(BufferedInputStream.java:336)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at org.wildfly.security.tool.Command.prompt(Command.java:100)
... 2 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1164) Wildfly Elytron Tool, credential-store command doesn't support redirection (<, <<) when multiple options are missing which show prompts.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1164?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek updated ELY-1164:
------------------------------
Component/s: Credential Store
> Wildfly Elytron Tool, credential-store command doesn't support redirection (<, <<) when multiple options are missing which show prompts.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1164
> URL: https://issues.jboss.org/browse/ELY-1164
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Wildfly Elytron Tool, credential-store command doesn't support redirection (<, <<) when multiple options are missing which show prompts.
> User omit --password and --secret options and then get two (four: there is confirmation) prompts but user isn't able to redirect data to second one.
> Expected behaviour is that it must work.
> *How to reproduce*
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --add secret_alias --create -l cs001.jceks --summary << EOF
> pass123
> pass123
> secret_value
> secret_value
> EOF
> {code}
> *has this output:*
> {code}
> Exception encountered executing the command:
> java.lang.Exception: java.io.IOException: Stream closed
> at org.wildfly.security.tool.Command.prompt(Command.java:115)
> at org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:184)
> at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:75)
> Caused by: java.io.IOException: Stream closed
> at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:170)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:336)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> at org.wildfly.security.tool.Command.prompt(Command.java:100)
> ... 2 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1162) WildFly Elytron Tool, add prompt when --secret is missing for Mask command.
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/ELY-1162?page=com.atlassian.jira.plugin.s... ]
Yeray Borges reassigned ELY-1162:
---------------------------------
Assignee: Yeray Borges (was: Darran Lofthouse)
> WildFly Elytron Tool, add prompt when --secret is missing for Mask command.
> ---------------------------------------------------------------------------
>
> Key: ELY-1162
> URL: https://issues.jboss.org/browse/ELY-1162
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Yeray Borges
> Priority: Blocker
>
> Add prompt when --secret is missing for Mask command.
> Use case:
> User have automation script using wildfly elytron tool and user don't want to have secret value stored in file.
> User don't want secret value to be stored in shell history after execution.
> User don't want secret value to be listed in ps -aux output.
> There have to be possibility to omit --secret. When omitting --secret attribute user interaction prompt should follow with possibility to input secret value.
> *How to reproduce*
> {code}
> java -jar wildfly-elytron-tool.jar mask -i 240 -s 12345678
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2820) Elytron, changing security-domain/mechanism-configurations of http-authentication-factory ends in reload-required state
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2820?page=com.atlassian.jira.plugi... ]
Martin Choma reassigned WFCORE-2820:
------------------------------------
Assignee: Tomas Hofman (was: Darran Lofthouse)
> Elytron, changing security-domain/mechanism-configurations of http-authentication-factory ends in reload-required state
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2820
> URL: https://issues.jboss.org/browse/WFCORE-2820
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Tomas Hofman
>
> Changing attributes {{security-domain}} and {{mechanism-configurations}} of http-authentication-factory does not apply immediatelly even though header allow-resource-service-restart=true is used
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=security-domain,value=ApplicationDomain){allow-resource-service-restart=true}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.UnsupportedOperationException",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=mechanism-configurations[0].host-name,value=localhost){allow-resource-service-restart=true}
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> Header should work as attributes are declared as {{"restart-required" => "resource-services"}}
> {code}
> "security-domain" => {
> "type" => STRING,
> "description" => "The SecurityDomain to associate with this resource",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => false,
> "capability-reference" => "org.wildfly.security.security-domain",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> }
> {code}
> And according to documentation [1]:
> resource-services – The operation can only immediately update the persistent configuration; applying the operation to the runtime will require a subsequent restart of some services associated with the resource. If the operation includes the request header "allow-resource-service-restart" => true, the handler for the operation will go ahead and restart the runtime service. Otherwise executing the operation will put the server into a "reload-required" state. (See the discussion of "all-services" above for more on the "reload-required" state.)
> [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen...
> Make allow-resource-service-restart=true work or if it is not achievable redefine restart-required model metadata appropriately, e.g. "all-services"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2820) Elytron, changing security-domain/mechanism-configurations of http-authentication-factory ends in reload-required state
by Martin Choma (JIRA)
Martin Choma created WFCORE-2820:
------------------------------------
Summary: Elytron, changing security-domain/mechanism-configurations of http-authentication-factory ends in reload-required state
Key: WFCORE-2820
URL: https://issues.jboss.org/browse/WFCORE-2820
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Changing attributes {{security-domain}} and {{mechanism-configurations}} of http-authentication-factory does not apply immediatelly even though header allow-resource-service-restart=true is used
{code}
[standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=security-domain,value=ApplicationDomain){allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.UnsupportedOperationException",
"rolled-back" => true
}
[standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=mechanism-configurations[0].host-name,value=localhost){allow-resource-service-restart=true}
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
{code}
Header should work as attributes are declared as {{"restart-required" => "resource-services"}}
{code}
"security-domain" => {
"type" => STRING,
"description" => "The SecurityDomain to associate with this resource",
"expressions-allowed" => false,
"required" => true,
"nillable" => false,
"capability-reference" => "org.wildfly.security.security-domain",
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
}
{code}
And according to documentation [1]:
resource-services – The operation can only immediately update the persistent configuration; applying the operation to the runtime will require a subsequent restart of some services associated with the resource. If the operation includes the request header "allow-resource-service-restart" => true, the handler for the operation will go ahead and restart the runtime service. Otherwise executing the operation will put the server into a "reload-required" state. (See the discussion of "all-services" above for more on the "reload-required" state.)
[1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen...
Make allow-resource-service-restart=true work or if it is not achievable redefine restart-required model metadata appropriately, e.g. "all-services"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-7091) Not able to configure list of key/trust managers on elytron ssl context.
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7091?page=com.atlassian.jira.plugin.... ]
Jan Kalina edited comment on WFLY-7091 at 5/17/17 8:20 AM:
-----------------------------------------------------------
The plural in "key-managers" refer to fact that *array of KeyManagers is output* of KeyManager factory - it does not mean it is possible to use more factories for one SSLContext.
was (Author: honza889):
The plural in "key-managers" refer to fact that array of KeyManagers is output of KeyManager factory - it does not mean it is possible to use more factories for one SSLContext.
> Not able to configure list of key/trust managers on elytron ssl context.
> ------------------------------------------------------------------------
>
> Key: WFLY-7091
> URL: https://issues.jboss.org/browse/WFLY-7091
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> Base on xsd/model documentation key-managers and trust-managers attributes seems to be meant to hold list of managers. That also comply to SSLContext init() method [1]. Hovewer, in elytron subsystem, they are of type string and any my tries to set list (space/comma delimited list) failed.
> XSD documentation
> * key-managers - Reference to the KeyManagers to be used by this SSLContext.
> * trust-managers - Reference to the TrustManagers to be used by this SSLContext.
> Model description:
> {noformat}
> "key-managers" => {
> "type" => STRING,
> "description" => "Reference to the key managers to use within the SSLContext.",
> "expressions-allowed" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.key-managers",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> "trust-managers" => {
> "type" => STRING,
> "description" => "Reference to the trust managers to use within the SSLContext.",
> "expressions-allowed" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.trust-managers",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> [1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html#i...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-7091) Not able to configure list of key/trust managers on elytron ssl context.
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7091?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7091:
----------------------------------
The plural in "key-managers" refer to fact that array of KeyManagers is output of KeyManager factory - it does not mean it is possible to use more factories for one SSLContext.
> Not able to configure list of key/trust managers on elytron ssl context.
> ------------------------------------------------------------------------
>
> Key: WFLY-7091
> URL: https://issues.jboss.org/browse/WFLY-7091
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> Base on xsd/model documentation key-managers and trust-managers attributes seems to be meant to hold list of managers. That also comply to SSLContext init() method [1]. Hovewer, in elytron subsystem, they are of type string and any my tries to set list (space/comma delimited list) failed.
> XSD documentation
> * key-managers - Reference to the KeyManagers to be used by this SSLContext.
> * trust-managers - Reference to the TrustManagers to be used by this SSLContext.
> Model description:
> {noformat}
> "key-managers" => {
> "type" => STRING,
> "description" => "Reference to the key managers to use within the SSLContext.",
> "expressions-allowed" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.key-managers",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> "trust-managers" => {
> "type" => STRING,
> "description" => "Reference to the trust managers to use within the SSLContext.",
> "expressions-allowed" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.trust-managers",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> [1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html#i...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8375) Some tests fail with security manager due to lack of permission to read EJB client
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-8375?page=com.atlassian.jira.plugin.... ]
Ivo Studensky reassigned WFLY-8375:
-----------------------------------
Assignee: Ivo Studensky
> Some tests fail with security manager due to lack of permission to read EJB client
> ----------------------------------------------------------------------------------
>
> Key: WFLY-8375
> URL: https://issues.jboss.org/browse/WFLY-8375
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.ejb.injection.ejbref.lookup.EjbRefLookupTestCase#testJBossEjbRefInRest*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=EjbRefLookupTestCase -Dsecurity.manager}}
> fails with:
> {code}
> ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /5e692792-50c7-4f07-8881-e7429386c843/rest/second/text: org.jboss.resteasy.spi.UnhandledException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/jtymel/jboss-eap/src/7.1/jboss-eap-7.1.0.DR13/dist/target/jboss-eap-7.1/modules/system/layers/base/org/jboss/ejb-client/main/jboss-ejb-client-4.0.0.Beta16-redhat-1.jar" "read")" in code source "(vfs:/content/5e692792-50c7-4f07-8881-e7429386c843.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78)
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> 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 org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46)
> 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$762.000000004C0FC080.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$763.000000004C1943A0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$763.000000004C1943A0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$763.000000004C1943A0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$763.000000004C1943A0.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:211)
> 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.io.FilePermission" "/home/jtymel/jboss-eap/src/7.1/jboss-eap-7.1.0.DR13/dist/target/jboss-eap-7.1/modules/system/layers/base/org/jboss/ejb-client/main/jboss-ejb-client-4.0.0.Beta16-redhat-1.jar" "read")" in code source "(vfs:/content/5e692792-50c7-4f07-8881-e7429386c843.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:901)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350)
> at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:158)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:102)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:135)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:163)
> at java.net.URL.openStream(URL.java:1057)
> at java.util.ServiceLoader.parse(ServiceLoader.java:315)
> at java.util.ServiceLoader.access$200(ServiceLoader.java:196)
> at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:368)
> at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:334)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:407)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:406)
> at java.security.AccessController.doPrivileged(AccessController.java:620)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:409)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:485)
> at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:435)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:130)
> at javax.naming.InitialContext.lookup(InitialContext.java:428)
> at javax.naming.InitialContext.lookup(InitialContext.java:428)
> at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices.doLookup(WeldEjbInjectionServices.java:247)
> at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices$1.createResource(WeldEjbInjectionServices.java:108)
> at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:49)
> at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:63)
> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:331)
> at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:117)
> at org.jboss.resteasy.cdi.JaxrsInjectionTarget.inject(JaxrsInjectionTarget.java:44)
> at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
> at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
> at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:177)
> at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> at org.jboss.as.test.integration.ejb.injection.ejbref.lookup.SecondRestService$Proxy$_$$_WeldClientProxy.getResultXML(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
> ... 50 more
> {code}
> Another affected tests found so far:
> *org.jboss.as.test.integration.ejb.remote.ejbnamespace.EjbNamespaceInvocationTestCase#testDirectLookup*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=EjbNamespaceInvocationTestCase -Dsecurity.manager}}
> *org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalWithNoDefaultSecurityDomainTestCase#testUnauthenticatedNoSecurityDomain*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=GetCallerPrincipalWithNoDefaultSecurityDomainTestCase -Dsecurity.manager}}
> *org.jboss.as.test.multinode.transaction.async.TransactionPropagationTestCase#testRemoteInvocation*
> *org.jboss.as.test.multinode.transaction.async.TransactionPropagationTestCase#testRemoteWithStatusAtRegistry*
> *org.jboss.as.test.multinode.transaction.async.TransactionPropagationTestCase#testRemoteWithStatusAtTransactionManager*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.multinode -Dtest=TransactionPropagationTestCase -Dsecurity.manager}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month