Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: security
    • Labels:
      None

      Description

      The security code uses the KrbException, Credentials, and PrincipalName classes from sun.security.krb5 and Krb5Util from sun.security.jgss.krb5. These may disappear in future Java releases. Also Hadoop does not compile using jdks that do not support them, for example with the following IBM JDK.

      $ /home/eli/toolchain/java-x86_64-60/bin/java -version
      java version "1.6.0"
      Java(TM) SE Runtime Environment (build pxa6460sr9fp1-20110208_03(SR9 FP1))
      IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr9-20110203_74623 (JIT enabled, AOT enabled)
      J9VM - 20110203_074623
      JIT  - r9_20101028_17488ifx3
      GC   - 20101027_AA)
      JCL  - 20110203_01
      

        Issue Links

          Activity

          Hide
          Todd Lipcon added a comment -

          HADOOP-6941 fixed compilation on the IBM JDK using reflection, but added some code which definitely does not work - eg:

                if (System.getProperty("java.vendor").contains("IBM")) {
                  principalClass = Class.forName("com.ibm.security.krb5.PrincipalName");
                  
                  credentialsClass = Class.forName("com.ibm.security.krb5.Credentials");
                  krb5utilClass = Class.forName("com.ibm.security.jgss.mech.krb5");
          

          but the krb5utilClass here is invalid, and there doesn't appear to be any equivalent in the IBM JDK. Instead of this code which kind of looks like it should work, we should just throw an UnsupportedOperationException until someone actually fixes this.

          Show
          Todd Lipcon added a comment - HADOOP-6941 fixed compilation on the IBM JDK using reflection, but added some code which definitely does not work - eg: if ( System .getProperty( "java.vendor" ).contains( "IBM" )) { principalClass = Class .forName( "com.ibm.security.krb5.PrincipalName" ); credentialsClass = Class .forName( "com.ibm.security.krb5.Credentials" ); krb5utilClass = Class .forName( "com.ibm.security.jgss.mech.krb5" ); but the krb5utilClass here is invalid, and there doesn't appear to be any equivalent in the IBM JDK. Instead of this code which kind of looks like it should work, we should just throw an UnsupportedOperationException until someone actually fixes this.
          Hide
          Luke Lu added a comment -

          This jira is incorporated by the patches in HADOOP-6941 and HADOOP-7211

          Show
          Luke Lu added a comment - This jira is incorporated by the patches in HADOOP-6941 and HADOOP-7211
          Hide
          Luke Lu added a comment -

          I meant HADOOP-8251

          Show
          Luke Lu added a comment - I meant HADOOP-8251
          Hide
          Todd Lipcon added a comment -

          This jira is incorporated by the patches in HADOOP-6941 and HADOOP-7211

          Did you mean another JIRA? This is HADOOP-7211

          Show
          Todd Lipcon added a comment - This jira is incorporated by the patches in HADOOP-6941 and HADOOP-7211 Did you mean another JIRA? This is HADOOP-7211
          Hide
          Todd Lipcon added a comment -

          I don't think this JIRA should be marked as duplicate, because clearly HADOOP-6941 wasn't thoroughly tested. As soon as I tried running a cluster with a 2NN I found that it didn't work. So I'm skeptical that there isn't more work to do...

          Show
          Todd Lipcon added a comment - I don't think this JIRA should be marked as duplicate, because clearly HADOOP-6941 wasn't thoroughly tested. As soon as I tried running a cluster with a 2NN I found that it didn't work. So I'm skeptical that there isn't more work to do...
          Hide
          Luke Lu added a comment -

          Since the changes that address this jira are already committed, IMO, it's reasonable to resolve this jira and open a different jira for defects and/or additional unit tests.

          Show
          Luke Lu added a comment - Since the changes that address this jira are already committed, IMO, it's reasonable to resolve this jira and open a different jira for defects and/or additional unit tests.
          Hide
          Devaraj Das added a comment - - edited

          On HADOOP-6941, my aim was to make the hadoop code base compile with IBM's JDK, and ensure that there is no regression with Oracle's. I had done testing of HDFS/MR with security enabled. I didn't do the tests that would go through the SecurityUtil code path though (argh) - fixed in HADOOP-8251.

          Show
          Devaraj Das added a comment - - edited On HADOOP-6941 , my aim was to make the hadoop code base compile with IBM's JDK, and ensure that there is no regression with Oracle's. I had done testing of HDFS/MR with security enabled. I didn't do the tests that would go through the SecurityUtil code path though (argh) - fixed in HADOOP-8251 .
          Hide
          Matt Foley added a comment -

          Resolved as dup, so removing Target Versions.

          Show
          Matt Foley added a comment - Resolved as dup, so removing Target Versions.
          Hide
          Eugene Koontz added a comment -

          I'm confused: which JIRA does this JIRA duplicate?

          Show
          Eugene Koontz added a comment - I'm confused: which JIRA does this JIRA duplicate?

            People

            • Assignee:
              Luke Lu
              Reporter:
              Eli Collins
            • Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development