4 Replies Latest reply on Jun 19, 2015 3:00 AM by georgespurlock

    VFS temp files and ProtectionDomain code source location

    mstruk
    mstruk May 14, 2010 9:42 AM

       

      I was thinking about https://jira.jboss.org/jira/browse/JBAS-7882 patch that exposes temp nested jar location to the outside world via VirtualFileHandler.getRealURL().

       

      This influences ProtectionDomain code source location of classes. I'm not very much into java security, but seems to me there might be an issue with security policies.

       

       

      If you have A.ear containing B.war containing C.jar, the archive to CodeSource location mapping would go like this (up to JBossAS-M2, I don't know about M3) ...

       

      Before patch:

       

      A.ear:   jar:file:/jboss/server/default/deploy/A.ear!/

      B.war:   jar:file:/jboss/server/default/deploy/A.ear!/B.war

      C.jar:    jar:file:/jboss/server/default/deploy/A.ear!/B.war



      After patch:

       


      A.ear:   jar:file:/jboss/server/default/deploy/A.ear!/

      B.war:   jar:file:/jboss/server/default/tmp/vfs-nested.tmp/02fd87ca_B.war!/

      C.jar:    jar:file:/jboss/server/default/tmp/vfs-nested.tmp/3cdf41da_C.jar!/



      Code source location can be used in security policy files as described here: http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html

      That means, anyone who uses a security policy file like:

      grant codeBase "jar:file:/jboss/server/default/deploy/A.ear!/*" {
      ...
      }
      would not have nested jars covered by this policy any more (as far as I understand).
      So there might be a backwards compatibility issue here?
      If my reasoning is correct, we would then also need to consider changing temp location for extracted nested jars ...
      Instead
         jar:file:/jboss/server/default/tmp/vfs-nested.tmp/3cdf41da_C.jar!/
      it should be something like:
         jar:file:/jboss/server/default/tmp/vfs-nested.tmp/A.ear/3cdf41da_C.jar!/
      maybe even:
         jar:file:/jboss/server/default/tmp/vfs-nested.tmp/A.ear/B.war/C.jar/3cdf41da_C.jar!/
      Cheers,
      - marko
      • 9429 Views
      • Tags:
        • 1. Re: VFS temp files and ProtectionDomain code source location
          alesj
          alesj May 14, 2010 9:53 AM (in response to mstruk)
          So there might be a backwards compatibility issue here?

          I think anything that involves exposing temp locations is wrong -- too much impl details.

          Which means we should then allow for direct vfs urls to be used in policy files.

          And this leads us back to

          * http://community.jboss.org/message/282687#282687

          * http://community.jboss.org/message/430978#430978

            • Actions
          • 2. Re: VFS temp files and ProtectionDomain code source location
            alesj
            alesj May 14, 2010 10:43 AM (in response to mstruk)
            A.ear:   jar:file:/jboss/server/default/deploy/A.ear!/

            B.war:   jar:file:/jboss/server/default/deploy/A.ear!/B.war

            C.jar:    jar:file:/jboss/server/default/deploy/A.ear!/B.war

             

            C.jar:    jar:file:/jboss/server/default/deploy/A.ear/B.war/WEB-INF/lib/C.jar!

            For this use case I would simply say "deploy as exploded" and it should work.

             

            Since

            (a) you don't wanna expose temp details

            (b) whatever URL you return should be useable (e.g. open jar file from it or JarURLConnection)

            and this two don't work together.

              • Actions
            • 3. Re: VFS temp files and ProtectionDomain code source location
              mstruk
              mstruk May 14, 2010 10:33 AM (in response to alesj)
              There are various dimensions to this problem.
              1) pushing some implementation details into public interface realm (temp files naming and structure)
              2) potential file locks on windows if exposing jar:file: urls to deploy location (as user code may then bypass vfs and use JarFile directly causing locks - preventing undeploy)
              3) using specific deployment scenario (expanded vs. packaged) tailored to specific requirements - third party libs working directly with jar:file: urls
              4) support for policy files
              In principle temp files naming should be an implementation detail. vfs3 for example doesn't use vfs-nested.tmp as far as I know. If this is exposed any future implementation will need to keep supporting the contract.
              From this point of view exposing jar:file: url to temp location is a no-no. The proper way to address JBAS-7882 issue is to deploy the application in expanded form. Policy file should then contain jar:file url patterns to deploy dir.
              Caveat is that by giving client jar:file urls to deploy jars, third party libs may lock them, preventing application undeploy via filesystem move/delete on windows.
              On the other hand, to avoid any possibility of file locking issues on windows, exposing direct jar:file: urls to deploy location is a no-no - all jar:file: should point to temp location, which then has to be predictible and properly structured. Policy files should then contain jar:file urls to temp location. In this case JBAS-7882 is covered by packaged deployment as well.
                • Actions
              • 4. Re: VFS temp files and ProtectionDomain code source location
                georgespurlock
                georgespurlock Jun 19, 2015 3:00 AM (in response to alesj)

                This package contain policy files and also properly structured to follow

                  • Actions