1 2 Previous Next 16 Replies Latest reply on Jan 7, 2008 2:32 PM by adrian.brock

    Security access

    alesj

      How is security enforced in our tests?
      Randomly? :-)

      I've introduced the code we were discussing here:
      - http://www.jboss.org/index.html?module=bb&op=viewtopic&t=123834&start=10
      --> wrapping the BeanInfo.set with MetaDataStack push, TCL change, PrivilegedAction execution if AccessControllerContext is present.

      When running ConfigTestSuite, I get all tests passing, except for all 3 ValueFactory(XML|Annotation)TestCase that fail due to security check in AbstractKernelControllerContext.getClassloader.

      What's the catch here, for all those tests that also execute that piece of code easily pass, but those three fail?

      3468 ERROR [AbstractKernelController] Error installing to Configured: name=PropHolder state=Instantiated
      java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)
       at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
       at java.security.AccessController.checkPermission(AccessController.java:427)
       at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
       at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.getClassLoader(AbstractKernelControllerContext.java:244)
       at org.jboss.kernel.plugins.dispatch.InvokeDispatchHelper.invoke(InvokeDispatchHelper.java:76)
       at org.jboss.beans.metadata.plugins.AbstractValueFactoryMetaData.getValue(AbstractValueFactoryMetaData.java:293)
       at org.jboss.beans.metadata.plugins.AbstractCollectionMetaData.getValue(AbstractCollectionMetaData.java:90)
       at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper.execute(PropertyDispatchWrapper.java:82)
       at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper$1.run(PropertyDispatchWrapper.java:96)
       at java.security.AccessController.doPrivileged(Native Method)
       at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:52)
       at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:108)
       at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:108)
       at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:88)
       at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:45)
       at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:135)
      


        • 1. Re: Security access
          alesj

          See revision 68200 for the 'live' example.

          • 2. Re: Security access
            starksm64

            You have to be running with a SecurityManager enabled to see this, which mean you need to have a valid security policy defined. The base test class that enables the SecurityManager should also be installing the test specific policy. I don't remember off the top of my head what this class is. The error you show means that the CodeSource for the current jboss-dependency.jar has not been granted the "java.lang.RuntimePermission getClassLoader" permission.

            • 3. Re: Security access
              alesj

              But why it works for some tests from ConfigTestSuite - that also use AbstractKernelControllerContext.getClassLoader (e.g. BeanMetaDataBuilderTestCase) - but not for those three?

              • 4. Re: Security access
                starksm64

                I would guess the answer lies in the loading of the test specific security configuration. Those that work have a policy file, those that don't either are not finding a policy file or have additional security checks that need permission grants.

                • 5. Re: Security access
                  alesj

                   

                  "scott.stark@jboss.org" wrote:
                  I would guess the answer lies in the loading of the test specific security configuration. Those that work have a policy file, those that don't either are not finding a policy file or have additional security checks that need permission grants.

                  I don't think there are any policy files, or at least I don't know where to find them.
                  And I'm also not aware of any additional permission checks that ValueFactoryTestCase would have and BeanMetaDataBuilderTestCase wouldn't.

                  I did add ValueFactoryTestCase.properties:
                  test.Permission.1=java.lang.RuntimePermission, getClassLoader
                  

                  w/o success.

                  Can you take MC's revision 68200 and see how org.jboss.test.kernel.config.test.ConfigTestSuite behaves for you?

                  Or you can run the current trunk and just change the ConfigureAction to use this
                   ExecutionWrapper wrapper = new PropertyDispatchWrapper(property, nullify, info, target, cl);
                   // FIXME - http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4112356
                   dispatchExecutionWrapper(context, wrapper);
                  // wrapper.execute(null);
                  


                  • 6. Re: Security access
                    starksm64

                    Ok, I'll take a look

                    • 7. Re: Security access
                      alesj

                      Thanks.

                      • 8. Re: Security access
                        starksm64

                        To get debugging from the SecurityManager layer, add a -Djava.security.debug=all to the run. It will print out a lot of info about the policy, access, and failures.

                        • 9. Re: Security access
                          alesj

                           

                          "scott.stark@jboss.org" wrote:
                          To get debugging from the SecurityManager layer, add a -Djava.security.debug=all to the run. It will print out a lot of info about the policy, access, and failures.

                          I already did that.
                          And it was really really a lot, so I gave up. :-(
                          But will re-try to find something useful. :-)

                          • 10. Re: Security access
                            starksm64

                            Send it to me and I should be able to see the relevant failure msg.

                            • 11. Re: Security access

                              I don't see these tests fail running under Maven or Eclipse.

                              So this must be something specific to your environment,
                              e.g. have you checked into a folder with the word "tests" in it?

                              The security policy used is here:
                              http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/test/trunk/src/main/java/org/jboss/test/security/TestsPolicyPlugin.java?revision=62656&view=markup

                               // Is this a test location?
                               File file = new File(url.toString());
                               String name = file.getName();
                               if (name.indexOf("tests") != -1 || name.indexOf("test-classes") != -1 || name.indexOf("-test.jar") != -1)
                              


                              What you need to do, is to print out the code source and permissions
                              for each of the class in the stacktrace until you reach one that has the permission.

                              Adding a privileged block makes no difference if that class doesn't have
                              the permission. In fact it makes it worse. ;-)

                              • 12. Re: Security access
                                alesj

                                 

                                "adrian@jboss.org" wrote:
                                I don't see these tests fail running under Maven or Eclipse.

                                So this must be something specific to your environment,
                                e.g. have you checked into a folder with the word "tests" in it?

                                Yup, IDEA copies test classes to tests-classes dir. :-(
                                Changing that to qests-classes did the trick. :-)

                                I commited ConfigureAction, so that it now uses the same wrapper code as Joinpoint notion did/does.

                                • 13. Re: Security access
                                  alesj

                                  Meant tests-classes --> qests-classes.

                                  • 14. Re: Security access
                                    starksm64

                                     

                                    "alesj" wrote:

                                    Yup, IDEA copies test classes to tests-classes dir. :-(

                                    We need to fine you for illegal development env usage.


                                    1 2 Previous Next