[JBoss JIRA] (WFCORE-1733) SynchServerOperationHandler doesn't check ops for REQUIRE_RESTART properly
by Ken Wills (JIRA)
Ken Wills created WFCORE-1733:
---------------------------------
Summary: SynchServerOperationHandler doesn't check ops for REQUIRE_RESTART properly
Key: WFCORE-1733
URL: https://issues.jboss.org/browse/WFCORE-1733
Project: WildFly Core
Issue Type: Bug
Reporter: Ken Wills
Assignee: Ken Wills
Currently, SyncServerStateOperationHandler makes a simple check to determine if the result of an op should put a server into restart-required. This should be fixed to check the AttributeDefinition for the target of a write-attribute for restart-required, and the OperationDefinition of all other ops.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1732) Servlet does not have permissions to read parent resources when deployed in EAR
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1732?page=com.atlassian.jira.plugi... ]
Ivo Studensky updated WFCORE-1732:
----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/8842, https://github.com/wildfly/wildfly-core/pull/1579, https://github.com/wildfly/wildfly-core/pull/1580, https://github.com/wildfly/wildfly-core/pull/1753 (was: https://github.com/wildfly/wildfly/pull/8842, https://github.com/wildfly/wildfly-core/pull/1579, https://github.com/wildfly/wildfly-core/pull/1580)
> Servlet does not have permissions to read parent resources when deployed in EAR
> -------------------------------------------------------------------------------
>
> Key: WFCORE-1732
> URL: https://issues.jboss.org/browse/WFCORE-1732
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> Servlet is provided with VFS mount points to be able to read resources from any library submodule packed in an EAR, but it does not have VirtualFilePermissions to do so when running with Security Manager enabled. This leads to the situation when the parent module corresponding to the EAR deployment does have VirtualFilePermissions to read resources from libraries packed in the deployment, but web submodules cannot reach them. Web submodules are provided only with permissions to its own resources like WEB-INF/classes etc. and they are missing the parent module permissions. See the following stack trace:
> *Stacktrace*
> {code}
> ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /deployment0/EarServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/lib/lib.jar/jar-info.txt" "read")" in code source "(vfs:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/deployment0.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 org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:253)
> at org.jboss.as.server.deployment.module.VFSResourceLoader$VFSEntryResource.openStream(VFSResourceLoader.java:327)
> at org.jboss.modules.Module.getResourceAsStream(Module.java:674)
> at org.jboss.modules.ModuleClassLoader.findResourceAsStream(ModuleClassLoader.java:546)
> at org.jboss.modules.ConcurrentClassLoader.getResourceAsStream(ConcurrentClassLoader.java:321)
> at org.jboss.as.test.integration.management.cli.EarServlet.doGet(EarServlet.java:19)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-565) A first boot SSLContext
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-565?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-565:
--------------------------------------
We have an implementation in WildFly Core that we need to mirror for this issue, it is not an ideal situation but we do need generated self signed - being an open source project everyone would have access to the private key if we shipped it.
> A first boot SSLContext
> -----------------------
>
> Key: ELY-565
> URL: https://issues.jboss.org/browse/ELY-565
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SSL
> Reporter: Darran Lofthouse
> Fix For: 1.1.0.Beta9
>
>
> For developers we have a requirement to be able to provide a working SSL set up before the user configures their own keys and certificates. We will need to tie this with our other SSL related tasks for fully configures set ups but we probably are also going to require an automatic mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1732) Servlet does not have permissions to read parent resources when deployed in EAR
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1732?page=com.atlassian.jira.plugi... ]
Ivo Studensky updated WFCORE-1732:
----------------------------------
Description:
Servlet is provided with VFS mount points to be able to read resources from any library submodule packed in an EAR, but it does not have VirtualFilePermissions to do so when running with Security Manager enabled. This leads to the situation when the parent module corresponding to the EAR deployment does have VirtualFilePermissions to read resources from libraries packed in the deployment, but web submodules cannot reach them. Web submodules are provided only with permissions to its own resources like WEB-INF/classes etc. and they are missing the parent module permissions. See the following stack trace:
*Stacktrace*
{code}
ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /deployment0/EarServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/lib/lib.jar/jar-info.txt" "read")" in code source "(vfs:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/deployment0.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 org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:253)
at org.jboss.as.server.deployment.module.VFSResourceLoader$VFSEntryResource.openStream(VFSResourceLoader.java:327)
at org.jboss.modules.Module.getResourceAsStream(Module.java:674)
at org.jboss.modules.ModuleClassLoader.findResourceAsStream(ModuleClassLoader.java:546)
at org.jboss.modules.ConcurrentClassLoader.getResourceAsStream(ConcurrentClassLoader.java:321)
at org.jboss.as.test.integration.management.cli.EarServlet.doGet(EarServlet.java:19)
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)
{code}
was:
Some tests fails due to java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" while run with security manager enabled.
*Affected tests found so far:*
* org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevel
* org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevelExploded
*How to reproduce*
* ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevel
* ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevelExploded
*Stacktrace*
{code}
ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /deployment0/EarServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/lib/lib.jar/jar-info.txt" "read")" in code source "(vfs:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/deployment0.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 org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:253)
at org.jboss.as.server.deployment.module.VFSResourceLoader$VFSEntryResource.openStream(VFSResourceLoader.java:327)
at org.jboss.modules.Module.getResourceAsStream(Module.java:674)
at org.jboss.modules.ModuleClassLoader.findResourceAsStream(ModuleClassLoader.java:546)
at org.jboss.modules.ConcurrentClassLoader.getResourceAsStream(ConcurrentClassLoader.java:321)
at org.jboss.as.test.integration.management.cli.EarServlet.doGet(EarServlet.java:19)
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)
{code}
> Servlet does not have permissions to read parent resources when deployed in EAR
> -------------------------------------------------------------------------------
>
> Key: WFCORE-1732
> URL: https://issues.jboss.org/browse/WFCORE-1732
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> Servlet is provided with VFS mount points to be able to read resources from any library submodule packed in an EAR, but it does not have VirtualFilePermissions to do so when running with Security Manager enabled. This leads to the situation when the parent module corresponding to the EAR deployment does have VirtualFilePermissions to read resources from libraries packed in the deployment, but web submodules cannot reach them. Web submodules are provided only with permissions to its own resources like WEB-INF/classes etc. and they are missing the parent module permissions. See the following stack trace:
> *Stacktrace*
> {code}
> ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /deployment0/EarServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/lib/lib.jar/jar-info.txt" "read")" in code source "(vfs:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/deployment0.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 org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:253)
> at org.jboss.as.server.deployment.module.VFSResourceLoader$VFSEntryResource.openStream(VFSResourceLoader.java:327)
> at org.jboss.modules.Module.getResourceAsStream(Module.java:674)
> at org.jboss.modules.ModuleClassLoader.findResourceAsStream(ModuleClassLoader.java:546)
> at org.jboss.modules.ConcurrentClassLoader.getResourceAsStream(ConcurrentClassLoader.java:321)
> at org.jboss.as.test.integration.management.cli.EarServlet.doGet(EarServlet.java:19)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1732) Servlet does not have permissions to read parent resources when deployed in EAR
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1732?page=com.atlassian.jira.plugi... ]
Ivo Studensky updated WFCORE-1732:
----------------------------------
Summary: Servlet does not have permissions to read parent resources when deployed in EAR (was: "org.jboss.vfs.VirtualFilePermission" by some tests in TS with security manager)
> Servlet does not have permissions to read parent resources when deployed in EAR
> -------------------------------------------------------------------------------
>
> Key: WFCORE-1732
> URL: https://issues.jboss.org/browse/WFCORE-1732
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> Some tests fails due to java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" while run with security manager enabled.
> *Affected tests found so far:*
> * org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevel
> * org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevelExploded
> *How to reproduce*
> * ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevel
> * ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevelExploded
> *Stacktrace*
> {code}
> ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /deployment0/EarServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/lib/lib.jar/jar-info.txt" "read")" in code source "(vfs:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/deployment0.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 org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:253)
> at org.jboss.as.server.deployment.module.VFSResourceLoader$VFSEntryResource.openStream(VFSResourceLoader.java:327)
> at org.jboss.modules.Module.getResourceAsStream(Module.java:674)
> at org.jboss.modules.ModuleClassLoader.findResourceAsStream(ModuleClassLoader.java:546)
> at org.jboss.modules.ConcurrentClassLoader.getResourceAsStream(ConcurrentClassLoader.java:321)
> at org.jboss.as.test.integration.management.cli.EarServlet.doGet(EarServlet.java:19)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1726:
----------------------------------------------
Hi Brian,
I thought at that, but it appears that the read-content operation only returns success. So it doesn't currently advertise the stream uuid it is returning. The loger file does return it.
Should we require an operation that returns a stream to have the uuid somewhere in the response?
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1726:
------------------------------------------
The streams in the response headers have uuids associated, so the responses can be searched for the matching uuid. There's a chance of misidentification but it it seems really remote.
I realize I'm talking in theory here and that the practical problems in implementing that might be large. My guess though is that any practical problems with the overall response handling logic being able to interact with the individual steps would be good ones to solve in general.
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months