1 2 3 Previous Next 116 Replies Latest reply on Nov 28, 2008 3:21 PM by anil.saldhana

    VFS Permissions - JBMICROCONT-149

      http://jira.jboss.com/jira/browse/JBMICROCONT-149

      I don't think the VFS is missing any permissions?

      If the caller doesn't have access to the file system then they
      shouldn't be able to use the VFS to bypass the security checks!

        • 1. Re: VFS Permissions - JBMICROCONT-149
          starksm64

          Correct. So far all priviledged blocks I have are part of the JBMICROCONT-150 subtask (VFS callers are missing privileged blocks).

          • 2. Re: VFS Permissions - JBMICROCONT-149
            anil.saldhana

            Scott, what needs to be done to get AS boot under a security manager.
            Any VFS related thing?
            https://jira.jboss.org/jira/browse/JBAS-4154

            Or are we back to this discussion?
            http://www.jboss.com/index.html?module=bb&op=viewtopic&t=143631

            • 3. Re: VFS Permissions - JBMICROCONT-149
              starksm64

              Yes, its back to having either vfs* url handlers available to the bootstrap lib or a Policy that deals with them. Its silly that CodeSource still uses a URL rather than URI since the URL contents are never used.

              • 4. Re: VFS Permissions - JBMICROCONT-149
                anil.saldhana

                 

                11:19:11,025 ERROR [AbstractKernelController] Error installing to Create: name=AspectManager state=Configured
                java.security.AccessControlException: access denied (java.io.FilePermission /home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/server/default/tmp/aopdynclasses read)
                 at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
                



                That is the error I am trying to get rid of that is not allowing a boot.

                • 5. Re: VFS Permissions - JBMICROCONT-149
                  dmlloyd

                  Just a note that vfs* handlers in the bootstrap lib don't have to be the real handlers, they can just be do-nothing stubs, since there is the opportunity to plug in a real URLStreamHandlerFactory at a later time.

                  • 6. Re: VFS Permissions - JBMICROCONT-149

                     

                    "anil.saldhana@jboss.com" wrote:
                    11:19:11,025 ERROR [AbstractKernelController] Error installing to Create: name=AspectManager state=Configured
                    java.security.AccessControlException: access denied (java.io.FilePermission /home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/server/default/tmp/aopdynclasses read)
                     at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
                    


                    That is the error I am trying to get rid of that is not allowing a boot.


                    You don't show the full stacktrace, but this is on the bootstrap thread
                    isn't it?
                    If you've correctly given all the jboss jars the AllPermission
                    then there shouldn't be any problem here with accessing the file system.

                    My guess is that you haven't given them the AllPermission because of the
                    code source being a vfs url.

                    • 7. Re: VFS Permissions - JBMICROCONT-149

                       

                      "david.lloyd@jboss.com" wrote:
                      Just a note that vfs* handlers in the bootstrap lib don't have to be the real handlers, they can just be do-nothing stubs, since there is the opportunity to plug in a real URLStreamHandlerFactory at a later time.


                      I'm not sure that would work. From my experience the URL stuff does
                      some funny caching?

                      An alternative solution is to change the way the VFSClassLoaderPolicy determines
                      the code source. i.e. instead of returning the vfs url we could hack it to return
                      a normal url.

                      But this would restrict codesources to be the top level url, you couldn't for
                      example have different permissions for subdeployments in the same deployment.

                      The relevant code is in VFSClassLoaderPolicy
                       @Override
                       protected ProtectionDomain getProtectionDomain(String className, String path)
                       {
                       VirtualFile clazz = findChild(path);
                       if (clazz == null)
                       {
                       log.trace("Unable to determine class file for " + className);
                       return null;
                       }
                       try
                       {
                       VirtualFile root = findRoot(path);
                      
                      // HERE!!!!!!!!
                      
                       URL codeSourceURL = root.toURL();
                      


                      This could for example be replaced with something like:
                      URL codeSourceURL = VFSUtils.getRealURLHack(root);
                      


                      An alternative solution would be to allow you to specify the codeSourceURL to use
                      for the classloader as a parameter when you create it.

                      The hack could then be in the jboss deployer that creates the classloader policy
                      rather than forcing it on every user of VFSClassLoaderPolicy.
                      i.e. people that use it standalone would probably include jboss-vfs.jar
                      in the classpath so the urls would be parsable?

                      • 8. Re: VFS Permissions - JBMICROCONT-149

                         

                        "adrian@jboss.org" wrote:

                        But this would restrict codesources to be the top level url, you couldn't for
                        example have different permissions for subdeployments in the same deployment.


                        IIRC the same restriction existed in JBoss4 because file and jar
                        urls can't describe subdeployments properly?

                        • 9. Re: VFS Permissions - JBMICROCONT-149
                          dmlloyd

                           

                          "adrian@jboss.org" wrote:
                          "david.lloyd@jboss.com" wrote:
                          Just a note that vfs* handlers in the bootstrap lib don't have to be the real handlers, they can just be do-nothing stubs, since there is the opportunity to plug in a real URLStreamHandlerFactory at a later time.


                          I'm not sure that would work. From my experience the URL stuff does
                          some funny caching?


                          When you set an application URLStreamHandlerFactory, it dumps the cache - it's the one and only opportunity you get to do so as far as I know.

                          • 10. Re: VFS Permissions - JBMICROCONT-149
                            anil.saldhana

                             

                            "adrian@jboss.org" wrote:
                            "anil.saldhana@jboss.com" wrote:
                            11:19:11,025 ERROR [AbstractKernelController] Error installing to Create: name=AspectManager state=Configured
                            java.security.AccessControlException: access denied (java.io.FilePermission /home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/server/default/tmp/aopdynclasses read)
                             at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
                            


                            That is the error I am trying to get rid of that is not allowing a boot.


                            You don't show the full stacktrace, but this is on the bootstrap thread
                            isn't it?
                            If you've correctly given all the jboss jars the AllPermission
                            then there shouldn't be any problem here with accessing the file system.

                            My guess is that you haven't given them the AllPermission because of the
                            code source being a vfs url.


                            Yeah, this is on bootstrap, trying to deploy aop.xml

                            Even with java.security.debug=all setting, I am not getting any debug info (including the protection domain that is failing). All I get is the error that I showed.

                            I will get back on this one.

                            • 11. Re: VFS Permissions - JBMICROCONT-149

                               

                              "david.lloyd@jboss.com" wrote:
                              "adrian@jboss.org" wrote:
                              "david.lloyd@jboss.com" wrote:
                              Just a note that vfs* handlers in the bootstrap lib don't have to be the real handlers, they can just be do-nothing stubs, since there is the opportunity to plug in a real URLStreamHandlerFactory at a later time.


                              I'm not sure that would work. From my experience the URL stuff does
                              some funny caching?


                              When you set an application URLStreamHandlerFactory, it dumps the cache - it's the one and only opportunity you get to do so as far as I know.


                              and that's spec defined or a current implementation detail of Sun's JRE? :-)

                              • 12. Re: VFS Permissions - JBMICROCONT-149
                                dmlloyd

                                I can't be 100% certain. But it seems to be implied in the JDK javadoc. They don't explicitly mention caching at all (that I can find), but they do state that the URLStreamHandlerFactory can be registered at most one time, and it will be used exclusively once it is registered; how can that be true if it maintains the cache beyond that moment in time?

                                • 13. Re: VFS Permissions - JBMICROCONT-149
                                  anil.saldhana

                                   

                                  12:02:47,182 DEBUG [ServerImpl] Deploying bootstrap xml:aop.xml
                                  ...
                                  12:02:49,414 DEBUG [Domain] org.jboss.classloading.spi.dependency.Domain@3b756456{DefaultDomain} add module VFSClassLoaderPolicyModule aop-classloader:0.0.0
                                  12:02:50,766 DEBUG [BaseClassLoader] Created BaseClassLoader@73e04a35{aop-classloader:0.0.0$MODULE} with policy VFSClassLoaderPolicy@a281902{name=aop-classloader:0.0.0$MODULE domain=null roots=[DelegatingHandler@1317132163[path= context=file:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-core.jar real=vfszip:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-core.jar], DelegatingHandler@778830265[path= context=file:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-jmx.jar real=vfszip:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-jmx.jar], DelegatingHandler@887435390[path= context=file:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-mc.jar real=vfszip:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-mc.jar], DelegatingHandler@852671315[path= context=file:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-jboss5.jar real=vfszip:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-jboss5.jar]] delegates=null exported=[META-INF.maven.org.jboss.aop.jboss-aop-asintegration-mc, META-INF, org.jboss.aop.deployers, org.jboss.aop.deployment, META-INF.maven.org.jboss.aop.jboss-aop-asintegration-core, org.jboss.aop.asintegration, org.jboss.aop.asintegration.jboss4, org.jboss.aop.asintegration.core, org.jboss.aop.domain, org.jboss.aop.classpool, org.jboss.aop.asintegration.jboss5, META-INF.maven.org.jboss.aop.jboss-aop-asintegration-jmx, ] <IMPORT-ALL>NON_EMPTY}
                                  
                                  java.security.AccessControlException: access denied (java.io.FilePermission /home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/server/default/tmp/aopdynclasses read)
                                   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 java.lang.SecurityManager.checkRead(SecurityManager.java:871)
                                   at java.io.File.exists(File.java:700)
                                   at org.jboss.aop.asintegration.core.AspectManagerServiceDelegate.create(AspectManagerServiceDelegate.java:236)
                                   at org.jboss.aop.deployers.AbstractAspectManager.create(AbstractAspectManager.java:89)
                                   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                                   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                                   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                                   at java.lang.reflect.Method.invoke(Method.java:585)
                                   at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
                                   at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
                                   at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
                                   at org.jboss.kernel.plugins.dependency.DispatchJoinPoint.run(DispatchJoinPoint.java:47)
                                   at java.security.AccessController.doPrivileged(Native Method)
                                   at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:54)
                                   at org.jboss.dependency.plugins.action.SimpleControllerContextAction.secureInstallAction(SimpleControllerContextAction.java:67)
                                   at org.jboss.dependency.plugins.action.AccessControllerContextAction$1.run(AccessControllerContextAction.java:80)
                                   at java.security.AccessController.doPrivileged(Native Method)
                                   at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:103)
                                   at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
                                   at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
                                   at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
                                   at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
                                   at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
                                   at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
                                   at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
                                   at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
                                   at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:331)
                                   at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:309)
                                   at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:331)
                                   at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:309)
                                   at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
                                   at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
                                   at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:88)
                                   at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:158)
                                   at org.jboss.bootstrap.microcontainer.ServerImpl.doStart(ServerImpl.java:116)
                                   at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:399)
                                   at org.jboss.Main.boot(Main.java:209)
                                   at org.jboss.Main$1.run(Main.java:544)
                                   at java.lang.Thread.run(Thread.java:595)
                                  12:03:08,344 DEBUG [ServerImpl] Deploying bootstrap xml:jmx.xml
                                  
                                  


                                  Ok, that is the stack trace for the record.

                                  • 14. Re: VFS Permissions - JBMICROCONT-149

                                     

                                    "anil.saldhana@jboss.com" wrote:

                                     at org.jboss.kernel.plugins.dependency.DispatchJoinPoint.run(DispatchJoinPoint.java:47)
                                     at java.security.AccessController.doPrivileged(Native Method)
                                     at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:54)
                                    


                                    Ok, that is the stack trace for the record.


                                    Well actually for the record, the stacktrace before that doPrivleged is irrelevant.
                                    What is relevant is the stacktrace when the pojo got registered (which should
                                    be pretty similar in this case?).

                                    In the MC we remember the AccessControlContext when you register
                                    the pojo and restore it when processing it. This avoids you gaining additional
                                    permissions by for example getting invoked on a different thread as your
                                    dependencies are satisfied.

                                    1 2 3 Previous Next