[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-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, https://github.com/wildfly/wildfly-core/pull/1753)
> 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
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (ELY-1144) External CS is missing key store location attribute
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1144?page=com.atlassian.jira.plugin.s... ]
Martin Choma reassigned ELY-1144:
---------------------------------
Assignee: Peter Skopek (was: Darran Lofthouse)
> External CS is missing key store location attribute
> ---------------------------------------------------
>
> Key: ELY-1144
> URL: https://issues.jboss.org/browse/ELY-1144
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: Peter Skopek
> Priority: Blocker
>
> External Credential Store - mechanism introduced as solution for EAP7-277 is missing parameter for specifying key store location.
> This is not necessary for PKCS11 keystore, which it was designed for in first place.
> However, if we left it in this way we loose posibility to ocnfigure file based keystores e.g. JKS, BCFKS (Bouncy Castle FIPS Key Store) ...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (ELY-1144) External CS is missing key store location attribute
by Martin Choma (JIRA)
Martin Choma created ELY-1144:
---------------------------------
Summary: External CS is missing key store location attribute
Key: ELY-1144
URL: https://issues.jboss.org/browse/ELY-1144
Project: WildFly Elytron
Issue Type: Bug
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
External Credential Store - mechanism introduced as solution for EAP7-277 is missing parameter for specifying key store location.
This is not necessary for PKCS11 keystore, which it was designed for in first place.
However, if we left it in this way we loose posibility to ocnfigure file based keystores e.g. JKS, BCFKS (Bouncy Castle FIPS Key Store) ...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (DROOLS-1541) newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1541?page=com.atlassian.jira.plugi... ]
Matteo Mortari resolved DROOLS-1541.
------------------------------------
Resolution: Cannot Reproduce Bug
> newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1541
> URL: https://issues.jboss.org/browse/DROOLS-1541
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.3.0.Final, 6.5.0.Final
> Reporter: Daniel B.
> Assignee: Matteo Mortari
>
> The identifier passed to the {{KieCommands.newInsert}} method's {{outIdentifier}} parameter and to the {{ExecutionResults.getValue}} method's {{identifier}} parameter doesn't actually refer to the fact object _via the fact handle_ as described in the documentation of {{InsertObjectCommand}}).
> The documentation says:
> {quote}
> 11.2.2. InsertObjectCommand
> ...
> outIdentifier Id to identify the FactHandle created in the object insertion and added to the execution results
> {quote}
> Although the Drools code in method {{InsertObjectCommand.execute}} does map the given identifier both to the original object and to the fact handle, the code in method {{ExecutionResultImpl.getValue}} retrieves the _original_ object instead of retrieving the object _currently associated with the fact handle_.
> This means that if the original fact object instance is replaced with a different instance (e.g., with {{update(kcontext.getKieRuntime().getFactHandle($oldObj), newObj);}} in the rules), then {{ExecutionResults.getValue}} will return the _original_ fact object, not the _current_ value of the fact object (the object instance currently associated with the fact handle created in the {{newInsert}} call).
> That in turn means that immutable fact object instances cannot be used with {{ExecutionResults.getValue}}.
> (It's not 100% clear that it's the code that is wrong (relative to the documentation) rather than it being documentation that's wrong (relative to the code). However, the behavior described by the documentation seems more useful than the behavior exhibited by the code.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (DROOLS-1541) newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1541?page=com.atlassian.jira.plugi... ]
Matteo Mortari reassigned DROOLS-1541:
--------------------------------------
Assignee: Matteo Mortari (was: Mario Fusco)
> newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1541
> URL: https://issues.jboss.org/browse/DROOLS-1541
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.3.0.Final, 6.5.0.Final
> Reporter: Daniel B.
> Assignee: Matteo Mortari
>
> The identifier passed to the {{KieCommands.newInsert}} method's {{outIdentifier}} parameter and to the {{ExecutionResults.getValue}} method's {{identifier}} parameter doesn't actually refer to the fact object _via the fact handle_ as described in the documentation of {{InsertObjectCommand}}).
> The documentation says:
> {quote}
> 11.2.2. InsertObjectCommand
> ...
> outIdentifier Id to identify the FactHandle created in the object insertion and added to the execution results
> {quote}
> Although the Drools code in method {{InsertObjectCommand.execute}} does map the given identifier both to the original object and to the fact handle, the code in method {{ExecutionResultImpl.getValue}} retrieves the _original_ object instead of retrieving the object _currently associated with the fact handle_.
> This means that if the original fact object instance is replaced with a different instance (e.g., with {{update(kcontext.getKieRuntime().getFactHandle($oldObj), newObj);}} in the rules), then {{ExecutionResults.getValue}} will return the _original_ fact object, not the _current_ value of the fact object (the object instance currently associated with the fact handle created in the {{newInsert}} call).
> That in turn means that immutable fact object instances cannot be used with {{ExecutionResults.getValue}}.
> (It's not 100% clear that it's the code that is wrong (relative to the documentation) rather than it being documentation that's wrong (relative to the code). However, the behavior described by the documentation seems more useful than the behavior exhibited by the code.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (DROOLS-1541) newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1541?page=com.atlassian.jira.plugi... ]
Matteo Mortari edited comment on DROOLS-1541 at 5/9/17 8:22 AM:
----------------------------------------------------------------
I don't believe there is an error in the documentation, neither there is an error in the code.
I believe the real problem here is mixing two api approaches, using the Commands Vs calling operations directly on the KieSession. Therefore, if one had to use only the Commands API, none of the mentioned issue would manifest.
Anyway, given the Commands API does not support the case of calling "update" and replacing the actual object instance, there could be an edge-case of mixing the two approaches.
But even in the case of mixing Commands API and calling operations directly on the KieSession, it is (still) *incorrect* to reuse a ExecutionResults after subsequent operations have been performed directly on the KieSession.
This is because ExecutionResults represents a "snapshot" of the results of the execution of the Commands, contextually to the KieSession.execute(Command c).
Once the execute returns a given ExecutionResults instance, the KieSession does NOT keep a reference to it, and that given instance will not be updated following subsequent KieSession API call. If the user want an updated ExecutionResults, it will require a new execute of Commands, which will return a consistent (new, up-to-date) ExecutionResults instance.
I want to stress the fact the ExecutionResults represent the result contextually to the Commands API call.
As an example see below, although I would NOT recommend it as it mixes Commands API and calling operations directly on the KieSession.
{code:java}
// Step1
ExecutionResults resultsA = session.execute(
CommandFactory.newBatchExecution( Arrays.asList(new Command[]{
CommandFactory.newInsert( new Measurement("color", "red"), "my_out_ID" ),
CommandFactory.newFireAllRules()
}))
);
FactHandle redFH = (FactHandle) resultsA.getFactHandle("my_out_ID");
// Step2
Object replacedInstance = new Measurement("color", "reddish");
session.update(redFH, replacedInstance );
session.fireAllRules();
// Step3
ExecutionResults resultsB = session.execute(
CommandFactory.newBatchExecution( Arrays.asList(new Command[]{
CommandFactory.newGetObject(redFH, "my_out_ID")
}))
);
assertEquals( replacedInstance, resultsB.getValue("my_out_ID") );
{code}
At step2, it would be INCORRECT to re-use the ExecutionResults coming from step1. The more correct approach in this case would be to retrieve an up-to-date ExecutionResults instance by calling a new execute Commands, i.e.: step3, notice the final assert statement
I hope this clarifies the misunderstanding.
If I incorrectly interpreted your original description, kindly let us know, please (eventually re-opening this jira)
Thank you,
MM
was (Author: tari_manga):
I don't believe there is an error in the documentation, neither there is an error in the code.
I believe the real problem here is mixing two api approaches, using the Commands Vs calling operations directly on the KieSession. Therefore, if one had to use only the Commands API, none of the mentioned issue would manifest.
Anyway, given the Commands API does not support the case of calling "update" and replacing the actual object instance, there could be an edge-case of mixing the two approaches.
But even in the case of mixing Commands API and calling operations directly on the KieSession, it is (still) *incorrect* to reuse a ExecutionResults after subsequent operations have been performed directly on the KieSession.
This is because ExecutionResults represents a "snapshot" of the results of the execution of the Commands, contextually to the KieSession.execute(Command c).
Once the execute returns a given ExecutionResults instance, the KieSession does NOT keep a reference to it, and that given instance will not be updated following subsequent KieSession API call. If the user want an updated ExecutionResults, it will require a new execute of Commands, which will return a consistent (new, up-to-date) ExecutionResults instance.
I want to stress the fact the ExecutionResults represent the result contextually to the Commands API call.
As an example see below, although I would NOT recommend it as it mixes Commands API and calling operations directly on the KieSession.
{code:java}
// Step1
ExecutionResults resultsA = session.execute(
CommandFactory.newBatchExecution( Arrays.asList(new Command[]{
CommandFactory.newInsert( new Measurement("color", "red"), "my_out_ID" ),
CommandFactory.newFireAllRules()
}))
);
FactHandle redFH = (FactHandle) resultsA.getFactHandle("my_out_ID");
// Step2
Object replacedInstance = new Measurement("color", "reddish");
session.update(redFH, replacedInstance );
session.fireAllRules();
// Step3
ExecutionResults resultsB = session.execute(
CommandFactory.newBatchExecution( Arrays.asList(new Command[]{
CommandFactory.newGetObject(redFH, "my_out_ID")
}))
);
assertEquals( replacedInstance, resultsB.getValue("my_out_ID") );
{code}
At step2, it would be INCORRECT to re-use the ExecutionResults coming from step1. The more correct approach in this case would be to retrieve an up-to-date ExecutionResults instance by calling a new execute Commands, i.e.: step3.
I hope this clarifies the misunderstanding.
If I incorrectly interpreted your original description, kindly let us know, please (eventually re-opening this jira)
Thank you,
MM
> newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1541
> URL: https://issues.jboss.org/browse/DROOLS-1541
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.3.0.Final, 6.5.0.Final
> Reporter: Daniel B.
> Assignee: Mario Fusco
>
> The identifier passed to the {{KieCommands.newInsert}} method's {{outIdentifier}} parameter and to the {{ExecutionResults.getValue}} method's {{identifier}} parameter doesn't actually refer to the fact object _via the fact handle_ as described in the documentation of {{InsertObjectCommand}}).
> The documentation says:
> {quote}
> 11.2.2. InsertObjectCommand
> ...
> outIdentifier Id to identify the FactHandle created in the object insertion and added to the execution results
> {quote}
> Although the Drools code in method {{InsertObjectCommand.execute}} does map the given identifier both to the original object and to the fact handle, the code in method {{ExecutionResultImpl.getValue}} retrieves the _original_ object instead of retrieving the object _currently associated with the fact handle_.
> This means that if the original fact object instance is replaced with a different instance (e.g., with {{update(kcontext.getKieRuntime().getFactHandle($oldObj), newObj);}} in the rules), then {{ExecutionResults.getValue}} will return the _original_ fact object, not the _current_ value of the fact object (the object instance currently associated with the fact handle created in the {{newInsert}} call).
> That in turn means that immutable fact object instances cannot be used with {{ExecutionResults.getValue}}.
> (It's not 100% clear that it's the code that is wrong (relative to the documentation) rather than it being documentation that's wrong (relative to the code). However, the behavior described by the documentation seems more useful than the behavior exhibited by the code.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months