[jboss-jira] [JBoss JIRA] (WFLY-11616) CDIBuiltinInjectionTestCase fails with a security manager installed

[Matej Novotny (Jira)]

    [ https://issues.jboss.org/browse/WFLY-11616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684494#comment-13684494 ] 

Matej Novotny commented on WFLY-11616:
--------------------------------------

Spec doesn't say anything about permissions, in fact [the only thing it says around {{Principal}}|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#additional_builtin_beans] is that there is a built-in bean with {{@Default}} qualifier provided. The rest is up to integrator (which, in Weld, is done via {{WeldSecurityServices}}).

I'll send a PR adding the privileged block.

> CDIBuiltinInjectionTestCase fails with a security manager installed
> -------------------------------------------------------------------
>
>                 Key: WFLY-11616
>                 URL: https://issues.jboss.org/browse/WFLY-11616
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Brian Stansberry
>            Assignee: Matej Novotny
>            Priority: Major
>
> New test case in https://github.com/wildfly/wildfly/pull/11996/files fails when a security manager is present.  This is a pre-existing problem not introduced by the PR. The PR is just the first test coverage we have of using @Inject Principal.
> I'll configure the test to be ignored if an s-m is present; this JIRA is to track a proper resolution.
> Details:
> {code}
> Caused by: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader")
>  at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:84)
>  at org.jboss.as.security.service.SimpleSecurityManager.getCallerPrincipal(SimpleSecurityManager.java:136)
>  at org.jboss.as.weld.services.bootstrap.WeldSecurityServices.getPrincipal(WeldSecurityServices.java:84)
>  at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:41)
>  at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:30)
>  at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:38)
>  at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
>  at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
>  at org.jboss.weld.security.Principal$$Proxy$_$$_Weld$Proxy$.getName(Unknown Source)
>  at org.jboss.as.test.integration.weld.builtin.CDIResource.getMessage(CDIResource.java:40)
>  at org.jboss.as.test.integration.weld.builtin.CDIResource$Proxy$_$$_WeldClientProxy.getMessage(Unknown Source)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
>  at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
>  at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
>  at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
>  at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
>  at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
>  at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
>  at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
>  at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
>  ... 57 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader")
>  at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
>  at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
>  at org.jboss.security.identity.plugins.IdentityFactory.loadClass(IdentityFactory.java:91)
>  at org.jboss.security.identity.plugins.IdentityFactory.createPrincipal(IdentityFactory.java:49)
>  at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:80)
>  ... 80 more
> {code}
> I don't know whether the spec has anything to say regarding any permissions that should be required in order to inject a Principal. If it says they shouldn't be required or is silent on the topic and we think they should not be necessary, then we are missing a privileged block.  Otherwise I doubt what's being thrown here is what we'd want. If some permission is needed, checking for something more related to the use case (probably something new) would be better, and if that permission check passes then make the call in a privileged block.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)