1 2 3 Previous Next 116 Replies Latest reply: Nov 28, 2008 3:21 PM by Anil Saldhana RSS

VFS Permissions - JBMICROCONT-149

Adrian Brock Master

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
    Scott Stark Master

    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 Master

    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
    Scott Stark Master

    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 Master

     

    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
    David Lloyd Master

    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
    Adrian Brock Master

     

    "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
    Adrian Brock Master

     

    "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 Brock Master

     

    "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
    David Lloyd Master

     

    "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 Master

     

    "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
    Adrian Brock Master

     

    "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
    David Lloyd Master

    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 Master

     

    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
    Adrian Brock Master

     

    "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