Hadoop Common
  1. Hadoop Common
  2. HADOOP-6452

Hadoop JSP pages don't work under a security manager

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 0.21.0
    • Fix Version/s: 0.21.0
    • Component/s: None
    • Labels:
      None

      Description

      When you run Hadoop under a security manager that says "yes" to all security checks, you get stack traces when Jetty tries to initialise the JSP engine. Which implies you can't use Jasper under a security manager

      1. hadoop-5740.patch
        2 kB
        steve_l
      2. mapreduce-439-2.patch
        2 kB
        steve_l
      3. HADOOP-6452-2.patch
        5 kB
        steve_l
      4. HADOOP-6452-3.patch
        5 kB
        steve_l

        Activity

        Hide
        steve_l added a comment -

        Stack trace
        code
        09/04/24 15:47:49 [JobTracker] INFO http.HttpServer : Jetty bound to port 50030
        09/04/24 15:47:49 [JobTracker] INFO mortbay.log : jetty-6.1.14
        09/04/24 15:47:49 [JobTracker] INFO mortbay.log : Extract jar:file:/home/slo/.ivy/cache/org.apache.hadoop/hadoop-core/jars/hadoop-core-0.21.0-alpha-9.jar!/webapps/job to work/Jetty_0_0_0_0_50030_job____yn7qmk/webapp
        09/04/24 15:47:49 [JobTracker] ERROR / : Security Init for context failed
        java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object
        at java.security.Permissions.add(Permissions.java:110)
        at java.security.Policy$UnsupportedEmptyCollection.add(Policy.java:790)
        at org.apache.jasper.compiler.JspRuntimeContext.initSecurity(JspRuntimeContext.java:564)
        at org.apache.jasper.compiler.JspRuntimeContext.<init>(JspRuntimeContext.java:198)
        at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:150)
        at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:431)
        at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:643)
        at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
        at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1234)
        at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
        at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:460)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
        at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
        at org.mortbay.jetty.Server.doStart(Server.java:222)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.apache.hadoop.http.HttpServer.start(HttpServer.java:454)
        at org.apache.hadoop.mapred.JobTracker.innerStart(JobTracker.java:1482)
        at org.apache.hadoop.util.Service.start(Service.java:186)
        code

        Show
        steve_l added a comment - Stack trace code 09/04/24 15:47:49 [JobTracker] INFO http.HttpServer : Jetty bound to port 50030 09/04/24 15:47:49 [JobTracker] INFO mortbay.log : jetty-6.1.14 09/04/24 15:47:49 [JobTracker] INFO mortbay.log : Extract jar: file:/home/slo/.ivy/cache/org.apache.hadoop/hadoop-core/jars/hadoop-core-0.21.0-alpha-9.jar!/webapps/job to work/Jetty_0_0_0_0_50030_job____yn7qmk/webapp 09/04/24 15:47:49 [JobTracker] ERROR / : Security Init for context failed java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object at java.security.Permissions.add(Permissions.java:110) at java.security.Policy$UnsupportedEmptyCollection.add(Policy.java:790) at org.apache.jasper.compiler.JspRuntimeContext.initSecurity(JspRuntimeContext.java:564) at org.apache.jasper.compiler.JspRuntimeContext.<init>(JspRuntimeContext.java:198) at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:150) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:431) at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:643) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1234) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:460) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:222) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.apache.hadoop.http.HttpServer.start(HttpServer.java:454) at org.apache.hadoop.mapred.JobTracker.innerStart(JobTracker.java:1482) at org.apache.hadoop.util.Service.start(Service.java:186) code
        Hide
        steve_l added a comment -

        1. This could be the same Jasper one we are seeing in hadoop
        https://issues.apache.org/bugzilla/show_bug.cgi?id=41509

        2. Discussion from Sun about how java6 changed part of the classloaders to return an immutable collection
        http://mail-archives.apache.org/mod_mbox/incubator-river-user/200810.mbox/%3C20081015181649.GB4649@east%3E

        Assuming these are released, Sun broke things in Java 6.

        Show
        steve_l added a comment - 1. This could be the same Jasper one we are seeing in hadoop https://issues.apache.org/bugzilla/show_bug.cgi?id=41509 2. Discussion from Sun about how java6 changed part of the classloaders to return an immutable collection http://mail-archives.apache.org/mod_mbox/incubator-river-user/200810.mbox/%3C20081015181649.GB4649@east%3E Assuming these are released, Sun broke things in Java 6.
        Hide
        steve_l added a comment -

        s/released/r/related

        Show
        steve_l added a comment - s/released/r/related
        Hide
        steve_l added a comment -

        Probable cause for this is that ConfiguredPolicy doesnt override PermissionCollection getPermissions(CodeSource codesource)

        In Java5 Policy.getPermissions(CodeSource codesource) returned a mutable PermissionCollection, but in Java6 that method returns an immutable one.

        This will be easy to test without running under a security manager, so easy to test that an overridden version of the method does the right thing

        Show
        steve_l added a comment - Probable cause for this is that ConfiguredPolicy doesnt override PermissionCollection getPermissions(CodeSource codesource) In Java5 Policy.getPermissions(CodeSource codesource) returned a mutable PermissionCollection, but in Java6 that method returns an immutable one. This will be easy to test without running under a security manager, so easy to test that an overridden version of the method does the right thing
        Hide
        Shevek added a comment -

        IIRC from my (once reasonable) knowledge of the Java security API, no assumptions are made by the Java security implementation about any returned value from any implementation of Policy, and (importantly for my previous work) the Policy is even free to return different values on each call. In contrast with (almost all) formal analyses of the model, the methods aren't even guaranteed to be called, depending on the dynamic context of the security check.

        Although I agree with the linked mail that Sun definitely changed the world, I suspect making assumptions about the behaviour of methods on Policy is dangerous.

        Show
        Shevek added a comment - IIRC from my (once reasonable) knowledge of the Java security API, no assumptions are made by the Java security implementation about any returned value from any implementation of Policy, and (importantly for my previous work) the Policy is even free to return different values on each call. In contrast with (almost all) formal analyses of the model, the methods aren't even guaranteed to be called, depending on the dynamic context of the security check. Although I agree with the linked mail that Sun definitely changed the world, I suspect making assumptions about the behaviour of methods on Policy is dangerous.
        Hide
        steve_l added a comment -

        Both jetty and RMI make assumptions that aren't valid, and as as they are code that isnt in the hadoop repository, it is up to the hadoop code to be changed to come to terms with their (mistaken) assumptions.

        I'm also adding my own code that tests the current policy and tries to add to it, printing out some diagnostics (including the classname) if it isn't writable. This is handy as the current policy may change over time.

        Is it ok to return a new empty permission collection on the getPermissions(CodeSource) call? It won't impact hadoop's own code.

        Show
        steve_l added a comment - Both jetty and RMI make assumptions that aren't valid, and as as they are code that isnt in the hadoop repository, it is up to the hadoop code to be changed to come to terms with their (mistaken) assumptions. I'm also adding my own code that tests the current policy and tries to add to it, printing out some diagnostics (including the classname) if it isn't writable. This is handy as the current policy may change over time. Is it ok to return a new empty permission collection on the getPermissions(CodeSource) call? It won't impact hadoop's own code.
        Hide
        steve_l added a comment -

        Already committed to the 3628 branch, this makes the codebase permission writable, and so passes a simple unit tests. Not yet tested under a proper security manager

        Show
        steve_l added a comment - Already committed to the 3628 branch, this makes the codebase permission writable, and so passes a simple unit tests. Not yet tested under a proper security manager
        Hide
        Shevek added a comment -

        Is it ok to return a new empty permission collection on the getPermissions(CodeSource) call? It won't impact hadoop's own code.

        In general, this will cause a SecurityManager to fail any permissions check involving code in a ProtectionDomain which was instantiated over that CodeSource. A CodeSource is (approximately) a URI, and a ProtectionDomain is effectively a Set of classes loaded from that URI with a common set of permissions.

        Forgive my lack of deep understanding of this specific instance of the application of the security manager, but in general, if ANY frame on the stack (AccessControlContext being a list of ProtectionDomains) has a PermssionCollection which does not contain the required permission, then the security check will fail. You might better relay or delegate the call and make a writable copy of the returned value from the underlying policy, otherwise you will break a great number of things very badly for anybody who does require a SecurityManager.

        With a little more understanding of the instance, I could be much more helpful. I am sorry that time forbids random speculative interest, but if you are stuck, I will gladly look further into it.

        Show
        Shevek added a comment - Is it ok to return a new empty permission collection on the getPermissions(CodeSource) call? It won't impact hadoop's own code. In general, this will cause a SecurityManager to fail any permissions check involving code in a ProtectionDomain which was instantiated over that CodeSource. A CodeSource is (approximately) a URI, and a ProtectionDomain is effectively a Set of classes loaded from that URI with a common set of permissions. Forgive my lack of deep understanding of this specific instance of the application of the security manager, but in general, if ANY frame on the stack (AccessControlContext being a list of ProtectionDomains) has a PermssionCollection which does not contain the required permission, then the security check will fail. You might better relay or delegate the call and make a writable copy of the returned value from the underlying policy, otherwise you will break a great number of things very badly for anybody who does require a SecurityManager. With a little more understanding of the instance, I could be much more helpful. I am sorry that time forbids random speculative interest, but if you are stuck, I will gladly look further into it.
        Hide
        steve_l added a comment -

        Hadoop doesn't work at all with a proper security manager, noted in HADOOP-5731, caused by the service level auth of HADOOP-4348.

        Even if you switch to a minimal security manager that blocks System.exit() calls (see HADOOP-4532 and HADOOP-5453) but doesnt delegate authorisation to the normal sun policy-driven code doesn't work, because libraries in Hadoop (here, jetty) and elsewhere RMI both check for a security manager being present, and if so, get the codebase's policy and add rights to it. That is, they assume that they can do this, and that it is needed.

        This patch lets both libraries get away with setting permissions, without paying any attention to the values. It is not a step towards hosting Hadoop under a fully functional security manager, but should be enough to run Hadoop under a simple manager that blocks exit calls unless asked very nicely.

        Now, ultimately, I would like to work with a Security Manager, but fixing that is going to require way more effort.

        Show
        steve_l added a comment - Hadoop doesn't work at all with a proper security manager, noted in HADOOP-5731 , caused by the service level auth of HADOOP-4348 . Even if you switch to a minimal security manager that blocks System.exit() calls (see HADOOP-4532 and HADOOP-5453 ) but doesnt delegate authorisation to the normal sun policy-driven code doesn't work, because libraries in Hadoop (here, jetty) and elsewhere RMI both check for a security manager being present, and if so, get the codebase's policy and add rights to it. That is, they assume that they can do this, and that it is needed. This patch lets both libraries get away with setting permissions, without paying any attention to the values. It is not a step towards hosting Hadoop under a fully functional security manager, but should be enough to run Hadoop under a simple manager that blocks exit calls unless asked very nicely. Now, ultimately, I would like to work with a Security Manager, but fixing that is going to require way more effort.
        Hide
        steve_l added a comment -

        This makes the permissions collection writable, so does not trigger failures in jetty or RMI code when trying to run with a security manager and a ConfiguredPolicy as the current (static, system-wide) policy.

        Show
        steve_l added a comment - This makes the permissions collection writable, so does not trigger failures in jetty or RMI code when trying to run with a security manager and a ConfiguredPolicy as the current (static, system-wide) policy.
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12406650/hadoop-5740.patch
        against trunk revision 769923.

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 3 new or modified tests.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 Eclipse classpath. The patch retains Eclipse classpath integrity.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed core unit tests.

        -1 contrib tests. The patch failed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/261/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/261/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/261/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/261/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12406650/hadoop-5740.patch against trunk revision 769923. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 Eclipse classpath. The patch retains Eclipse classpath integrity. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. -1 contrib tests. The patch failed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/261/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/261/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/261/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/261/console This message is automatically generated.
        Hide
        steve_l added a comment -

        The test that failed is
        org.apache.hadoop.mapred.TestQueueCapacities.testSingleQueue
        Error Message

        Timeout occurred. Please note the time in the report does not reflect the time until the timeout.

        -I don't see how that could be related to the overriding of a new (and previously unused) method in the Policy subclass

        Show
        steve_l added a comment - The test that failed is org.apache.hadoop.mapred.TestQueueCapacities.testSingleQueue Error Message Timeout occurred. Please note the time in the report does not reflect the time until the timeout. -I don't see how that could be related to the overriding of a new (and previously unused) method in the Policy subclass
        Hide
        Chris Douglas added a comment -

        The patch needs to be regenerated

        Show
        Chris Douglas added a comment - The patch needs to be regenerated
        Hide
        steve_l added a comment -

        yes, I will do this. The code is checked in to my branch of hadoop-common; nothing complex

        Show
        steve_l added a comment - yes, I will do this. The code is checked in to my branch of hadoop-common; nothing complex
        Hide
        steve_l added a comment -

        Updated patch. Although this bug is filed under MAPREDUCE, and surfaces there and in hdfs, the patch is actually for hadoop-common source

        Show
        steve_l added a comment - Updated patch. Although this bug is filed under MAPREDUCE, and surfaces there and in hdfs, the patch is actually for hadoop-common source
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12428156/mapreduce-439-2.patch
        against trunk revision 891111.

        +1 @author. The patch does not contain any @author tags.

        -1 tests included. The patch doesn't appear to include any new or modified tests.
        Please justify why no new tests are needed for this patch.
        Also please list what manual steps were performed to verify this patch.

        -1 patch. The patch command could not apply the patch.

        Console output: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h3.grid.sp2.yahoo.net/202/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428156/mapreduce-439-2.patch against trunk revision 891111. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. -1 patch. The patch command could not apply the patch. Console output: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h3.grid.sp2.yahoo.net/202/console This message is automatically generated.
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12428156/mapreduce-439-2.patch
        against trunk revision 891511.

        +1 @author. The patch does not contain any @author tags.

        -1 tests included. The patch doesn't appear to include any new or modified tests.
        Please justify why no new tests are needed for this patch.
        Also please list what manual steps were performed to verify this patch.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed core unit tests.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/215/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/215/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/215/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/215/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428156/mapreduce-439-2.patch against trunk revision 891511. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/215/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/215/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/215/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/215/console This message is automatically generated.
        Hide
        Tom White added a comment -

        This looks reasonable to me. Is it possible to write a test for it? If not, can you describe the manual test you ran please?

        Show
        Tom White added a comment - This looks reasonable to me. Is it possible to write a test for it? If not, can you describe the manual test you ran please?
        Hide
        steve_l added a comment -

        Trying to run under a security manager is a bit convoluted; you'd need to bring up a process under one. You can't assume your unit test suite is allowed to play with security managers as IDEs and even <junit> may use them to stop calls to System.exit() working.

        What I could test for is what triggered the problem in the stack trace, the attempt to add permissions to the permissions object retrieved with getPermissions(). That object has to support addPermissions(), which the default clearly does not. This test should fit into a normal unit test method

        Show
        steve_l added a comment - Trying to run under a security manager is a bit convoluted; you'd need to bring up a process under one. You can't assume your unit test suite is allowed to play with security managers as IDEs and even <junit> may use them to stop calls to System.exit() working. What I could test for is what triggered the problem in the stack trace, the attempt to add permissions to the permissions object retrieved with getPermissions(). That object has to support addPermissions(), which the default clearly does not. This test should fit into a normal unit test method
        Hide
        steve_l added a comment -

        I have a test for this, this is the test failure you get before the patch to ConfiguredPolicy is applied

        Testsuite: org.apache.hadoop.security.authorize.TestConfiguredPolicy
        Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 0.532 sec
        ------------- Standard Output ---------------
        2009-12-21 14:30:00,089 WARN  conf.Configuration (Configuration.java:<clinit>(347)) - DEPRECATED: hadoop-site.xml found in the classpath. Usage of hadoop-site.xml is deprecated. Instead use core-site.xml, mapred-site.xml and hdfs-site.xml to override properties of core-default.xml, mapred-default.xml and hdfs-default.xml respectively
        2009-12-21 14:30:00,265 INFO  authorize.ServiceAuthorizationManager (ServiceAuthorizationManager.java:run(92)) - Authorization failed for joe,users
        java.security.AccessControlException: access denied ConnectionPermission(org.apache.hadoop.security.authorize.TestConfiguredPolicy$Protocol2)
        	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        	at java.security.AccessController.checkPermission(AccessController.java:546)
        	at org.apache.hadoop.security.authorize.ServiceAuthorizationManager$1.run(ServiceAuthorizationManager.java:89)
        	at org.apache.hadoop.security.authorize.ServiceAuthorizationManager$1.run(ServiceAuthorizationManager.java:84)
        	at java.security.AccessController.doPrivileged(Native Method)
        	at javax.security.auth.Subject.doAs(Subject.java:396)
        	at org.apache.hadoop.security.authorize.ServiceAuthorizationManager.checkPermission(ServiceAuthorizationManager.java:83)
        	at org.apache.hadoop.security.authorize.ServiceAuthorizationManager.authorize(ServiceAuthorizationManager.java:68)
        	at org.apache.hadoop.security.authorize.TestConfiguredPolicy.testConfiguredPolicy(TestConfiguredPolicy.java:79)
        	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:597)
        	at junit.framework.TestCase.runTest(TestCase.java:168)
        	at junit.framework.TestCase.runBare(TestCase.java:134)
        	at junit.framework.TestResult$1.protect(TestResult.java:110)
        	at junit.framework.TestResult.runProtected(TestResult.java:128)
        	at junit.framework.TestResult.run(TestResult.java:113)
        	at junit.framework.TestCase.run(TestCase.java:124)
        	at junit.framework.TestSuite.runTest(TestSuite.java:232)
        	at junit.framework.TestSuite.run(TestSuite.java:227)
        	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:79)
        	at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
        	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
        	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:921)
        	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:778)
        ------------- ---------------- ---------------
        
        Testcase: testConfiguredPolicy took 0.294 sec
        Testcase: testPolicyWriteable took 0.127 sec
        	Caused an ERROR
        attempt to add a Permission to a readonly Permissions object
        java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object
        	at java.security.Permissions.add(Permissions.java:110)
        	at java.security.Policy$UnsupportedEmptyCollection.add(Policy.java:790)
        	at org.apache.hadoop.security.authorize.TestConfiguredPolicy.assertWriteable(TestConfiguredPolicy.java:115)
        	at org.apache.hadoop.security.authorize.TestConfiguredPolicy.testPolicyWriteable(TestConfiguredPolicy.java:127)
        
        Testcase: testProtectionDomainPolicyWriteable took 0.092 sec
        
        Show
        steve_l added a comment - I have a test for this, this is the test failure you get before the patch to ConfiguredPolicy is applied Testsuite: org.apache.hadoop.security.authorize.TestConfiguredPolicy Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 0.532 sec ------------- Standard Output --------------- 2009-12-21 14:30:00,089 WARN conf.Configuration (Configuration.java:<clinit>(347)) - DEPRECATED: hadoop-site.xml found in the classpath. Usage of hadoop-site.xml is deprecated. Instead use core-site.xml, mapred-site.xml and hdfs-site.xml to override properties of core- default .xml, mapred- default .xml and hdfs- default .xml respectively 2009-12-21 14:30:00,265 INFO authorize.ServiceAuthorizationManager (ServiceAuthorizationManager.java:run(92)) - Authorization failed for joe,users java.security.AccessControlException: access denied ConnectionPermission(org.apache.hadoop.security.authorize.TestConfiguredPolicy$Protocol2) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at org.apache.hadoop.security.authorize.ServiceAuthorizationManager$1.run(ServiceAuthorizationManager.java:89) at org.apache.hadoop.security.authorize.ServiceAuthorizationManager$1.run(ServiceAuthorizationManager.java:84) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.authorize.ServiceAuthorizationManager.checkPermission(ServiceAuthorizationManager.java:83) at org.apache.hadoop.security.authorize.ServiceAuthorizationManager.authorize(ServiceAuthorizationManager.java:68) at org.apache.hadoop.security.authorize.TestConfiguredPolicy.testConfiguredPolicy(TestConfiguredPolicy.java:79) 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:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:79) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:921) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:778) ------------- ---------------- --------------- Testcase: testConfiguredPolicy took 0.294 sec Testcase: testPolicyWriteable took 0.127 sec Caused an ERROR attempt to add a Permission to a readonly Permissions object java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object at java.security.Permissions.add(Permissions.java:110) at java.security.Policy$UnsupportedEmptyCollection.add(Policy.java:790) at org.apache.hadoop.security.authorize.TestConfiguredPolicy.assertWriteable(TestConfiguredPolicy.java:115) at org.apache.hadoop.security.authorize.TestConfiguredPolicy.testPolicyWriteable(TestConfiguredPolicy.java:127) Testcase: testProtectionDomainPolicyWriteable took 0.092 sec
        Hide
        steve_l added a comment -

        patch with a test

        Show
        steve_l added a comment - patch with a test
        Hide
        Hadoop QA added a comment -

        +1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12428645/HADOOP-6452-2.patch
        against trunk revision 892113.

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 3 new or modified tests.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed core unit tests.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/228/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/228/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/228/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/228/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428645/HADOOP-6452-2.patch against trunk revision 892113. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/228/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/228/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/228/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/228/console This message is automatically generated.
        Hide
        Tom White added a comment -

        +1

        A nit: there are a couple of places where the indentation introduced by the patch isn't correct.

        Show
        Tom White added a comment - +1 A nit: there are a couple of places where the indentation introduced by the patch isn't correct.
        Hide
        steve_l added a comment -

        Committed with the whitespace sorted out. I need to keep an eye on the IDE.

        Show
        steve_l added a comment - Committed with the whitespace sorted out. I need to keep an eye on the IDE.
        Hide
        Hudson added a comment -

        Integrated in Hadoop-Common-trunk-Commit #126 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk-Commit/126/)
        Hadoop JSP pages don't work under a security manager

        Show
        Hudson added a comment - Integrated in Hadoop-Common-trunk-Commit #126 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk-Commit/126/ ) Hadoop JSP pages don't work under a security manager
        Hide
        steve_l added a comment -

        This is the patch as applied, same as -2 but with the whitespace corrected.

        Show
        steve_l added a comment - This is the patch as applied, same as -2 but with the whitespace corrected.
        Hide
        Hudson added a comment -

        Integrated in Hadoop-Common-trunk #197 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/197/)
        Hadoop JSP pages don't work under a security manager

        Show
        Hudson added a comment - Integrated in Hadoop-Common-trunk #197 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/197/ ) Hadoop JSP pages don't work under a security manager

          People

          • Assignee:
            Steve Loughran
            Reporter:
            Steve Loughran
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development