[JBoss JIRA] (CDI-727) CDI.current() should use privileged block
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-727 started by Antoine Sabot-Durand.
------------------------------------------------
> CDI.current() should use privileged block
> -----------------------------------------
>
> Key: CDI-727
> URL: https://issues.jboss.org/browse/CDI-727
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Affects Versions: 2.0 .Final
> Reporter: Jan Kalina
> Assignee: Antoine Sabot-Durand
> Labels: security-manager
> Fix For: 2.0.SP1
>
>
> When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR.
> *{{CDI.findAllProviders}} method should read the JAR in privileged block.*
> (as discussed in WFLY-10125)
> {code}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360)
> at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152)
> at java.net.URL.openStream(URL.java:1045)
> at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109)
> at javax.enterprise.inject.spi.CDI.current(CDI.java:53)
> at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (CDI-699) AnnotationLiteral should use privileged actions for reflective operations
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-699?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-699 started by Antoine Sabot-Durand.
------------------------------------------------
> AnnotationLiteral should use privileged actions for reflective operations
> -------------------------------------------------------------------------
>
> Key: CDI-699
> URL: https://issues.jboss.org/browse/CDI-699
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Labels: security-manager
> Fix For: 2.0.SP1
>
>
> Currently, if an application declares its own literal which extends {{AnnotationLiteral}} and is run with {{SecurityManager}} enabled, some methods might lead to {{SecurityException}} (e.g. {{AnnotationLiteral.getMembers()}} called in constructor requires {{accessDeclaredMembers}} permission). The only possible fix seems to be to grant the permission to the deployment/application which is not very convenient. If privileged actions were used, the app server could grant the permissions to the provided CDI API module only.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (CDI-699) AnnotationLiteral should use privileged actions for reflective operations
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-699?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-699:
----------------------------------------
Assignee: Antoine Sabot-Durand
> AnnotationLiteral should use privileged actions for reflective operations
> -------------------------------------------------------------------------
>
> Key: CDI-699
> URL: https://issues.jboss.org/browse/CDI-699
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Labels: security-manager
> Fix For: 2.0.SP1
>
>
> Currently, if an application declares its own literal which extends {{AnnotationLiteral}} and is run with {{SecurityManager}} enabled, some methods might lead to {{SecurityException}} (e.g. {{AnnotationLiteral.getMembers()}} called in constructor requires {{accessDeclaredMembers}} permission). The only possible fix seems to be to grant the permission to the deployment/application which is not very convenient. If privileged actions were used, the app server could grant the permissions to the provided CDI API module only.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (CDI-727) CDI.current() should use privileged block
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-727:
----------------------------------------
Assignee: Antoine Sabot-Durand
> CDI.current() should use privileged block
> -----------------------------------------
>
> Key: CDI-727
> URL: https://issues.jboss.org/browse/CDI-727
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Affects Versions: 2.0 .Final
> Reporter: Jan Kalina
> Assignee: Antoine Sabot-Durand
> Labels: security-manager
> Fix For: 2.0.SP1
>
>
> When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR.
> *{{CDI.findAllProviders}} method should read the JAR in privileged block.*
> (as discussed in WFLY-10125)
> {code}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360)
> at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152)
> at java.net.URL.openStream(URL.java:1045)
> at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109)
> at javax.enterprise.inject.spi.CDI.current(CDI.java:53)
> at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (CDI-727) CDI.current() should use privileged block
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-727:
-------------------------------------
Fix Version/s: 2.0.SP1
> CDI.current() should use privileged block
> -----------------------------------------
>
> Key: CDI-727
> URL: https://issues.jboss.org/browse/CDI-727
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Affects Versions: 2.0 .Final
> Reporter: Jan Kalina
> Labels: security-manager
> Fix For: 2.0.SP1
>
>
> When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR.
> *{{CDI.findAllProviders}} method should read the JAR in privileged block.*
> (as discussed in WFLY-10125)
> {code}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360)
> at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152)
> at java.net.URL.openStream(URL.java:1045)
> at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109)
> at javax.enterprise.inject.spi.CDI.current(CDI.java:53)
> at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (CDI-699) AnnotationLiteral should use privileged actions for reflective operations
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-699?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-699:
-------------------------------------
Fix Version/s: 2.0.SP1
(was: 2.1 (Discussion))
> AnnotationLiteral should use privileged actions for reflective operations
> -------------------------------------------------------------------------
>
> Key: CDI-699
> URL: https://issues.jboss.org/browse/CDI-699
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Reporter: Martin Kouba
> Labels: security-manager
> Fix For: 2.0.SP1
>
>
> Currently, if an application declares its own literal which extends {{AnnotationLiteral}} and is run with {{SecurityManager}} enabled, some methods might lead to {{SecurityException}} (e.g. {{AnnotationLiteral.getMembers()}} called in constructor requires {{accessDeclaredMembers}} permission). The only possible fix seems to be to grant the permission to the deployment/application which is not very convenient. If privileged actions were used, the app server could grant the permissions to the provided CDI API module only.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (CDI-729) Async event not CompletionStage friendly
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau edited comment on CDI-729 at 6/20/18 4:33 AM:
-----------------------------------------------------------------
[~mkouba] how do you embrace the rich semantic without the stage as a param? If you drop it then it means you just use thenCompose which is a very small portion of the API. No acceptEither etc...
If they are notified in parallel you get N stages and can replace the "submitted" stage by the returned one to notify the completion to the caller. This is the goal of the returned instance.
In summary: param = rich compose API with fallback support etc, returned type = enrichment of the "wait" logic of the returned instance to the caller to give caller the guarantee all is done (= same guarantee than in sync mode but reactive style)
was (Author: rmannibucau):
[~mkouba] how do you embrace the rich semantic without the stage as a param? If you drop it then it means you just use thenCompose which is a very small portion of the API. No acceptEither etc...
If they are notified in parallel you get N stages and can replace the "submitted" stage by the returned one to notify the completion to the caller. This is the goal of the returned instance.
In summary: param = rich compose API with fallback support etc, returned type = enrichment of the "wait" logic of the returned instance to the caller to give caller the guarantee all is execpted (= same guarantee than in sync mode but reactive style)
> Async event not CompletionStage friendly
> ----------------------------------------
>
> Key: CDI-729
> URL: https://issues.jboss.org/browse/CDI-729
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched.
> Here is a sample:
> 1. fireAsync(persistEvent)
> 2. observer implementation does: return future.thenCompose(db::doAsyncPersist)
> 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (CDI-729) Async event not CompletionStage friendly
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-729:
----------------------------------------
[~mkouba] how do you embrace the rich semantic without the stage as a param? If you drop it then it means you just use thenCompose which is a very small portion of the API. No acceptEither etc...
If they are notified in parallel you get N stages and can replace the "submitted" stage by the returned one to notify the completion to the caller. This is the goal of the returned instance.
In summary: param = rich compose API with fallback support etc, returned type = enrichment of the "wait" logic of the returned instance to the caller to give caller the guarantee all is execpted (= same guarantee than in sync mode but reactive style)
> Async event not CompletionStage friendly
> ----------------------------------------
>
> Key: CDI-729
> URL: https://issues.jboss.org/browse/CDI-729
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched.
> Here is a sample:
> 1. fireAsync(persistEvent)
> 2. observer implementation does: return future.thenCompose(db::doAsyncPersist)
> 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (CDI-729) Async event not CompletionStage friendly
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-729:
----------------------------------
bq. To enable exceptionally and friends...
[~rmannibucau] I still don't get it. What does the {{CompletionStage}} param represent and why is it needed? IMHO an observer should not care about what happened before/after its notification.
Also note that async observers can be notified in parallel.
I can see a lot of misunderstanding in the comments which indicates that this topic is difficult. But otherwise it's a good discussion. Keep going ;-).
> Async event not CompletionStage friendly
> ----------------------------------------
>
> Key: CDI-729
> URL: https://issues.jboss.org/browse/CDI-729
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched.
> Here is a sample:
> 1. fireAsync(persistEvent)
> 2. observer implementation does: return future.thenCompose(db::doAsyncPersist)
> 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months