Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-11616

CDIBuiltinInjectionTestCase fails with a security manager installed

    XMLWordPrintable

Details

    Description

      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:

      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

      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.

      Attachments

        Issue Links

          is related to

          Bug - A problem that impairs or prevents the functions of the product. WFLY-11587 org.jboss.as.weld has optional dependency on org.jboss.as.security which causes regression

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              manovotn Matěj Novotný
              bstansbe@redhat.com Brian Stansberry
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: