Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Mon, 3 Feb 2014 17:50:10 +0000 (UTC)
From: "Alejandro Abdelnur (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12682724.1386176397814.27938.1391449810332@arcas>
In-Reply-To: <JIRA.12682724.1386176397814@arcas>
References: <JIRA.12682724.1386176397814@arcas>
Subject: [jira] [Commented] (HADOOP-10158) SPNEGO should work with multiple
 interfaces/SPNs.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HADOOP-10158?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13=
889675#comment-13889675 ]=20

Alejandro Abdelnur commented on HADOOP-10158:
---------------------------------------------

KerberosAuthenticationHandler.java:

* loginPrincipal(), it seems it is not considering the case of a 'HTTP@REAL=
M' principal and it would assume it is correct.

* getLoginForHost():

{code}
        SpnegoLogin newLogin =3D new SpnegoLogin(principal);
        spnegoLogin =3D logins.putIfAbsent(host, newLogin);
        if (spnegoLogin =3D=3D null) {
          spnegoLogin =3D newLogin;
        }
        spnegoLogin.login(keytab);
{code}

We should add a comment on the spnegoLogin.login(keytab) invocation that in=
 the case of a race condition the second login attempt is a NOP.

KerberosUtil.java:

* getRealmForHost(), typo s/retun/return/. Please add an 'IMPORTANT:=E2=80=
=99 comment here explaining we are tapping into implementation specific met=
hods of the Oracle and IBM JDKs, it may break in other JDKs or in future ve=
rsions, and it may blow if a SecurityManager is in place.


> SPNEGO should work with multiple interfaces/SPNs.
> -------------------------------------------------
>
>                 Key: HADOOP-10158
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10158
>             Project: Hadoop Common
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Kihwal Lee
>            Assignee: Daryn Sharp
>            Priority: Critical
>         Attachments: HADOOP-10158-readkeytab.patch, HADOOP-10158-readkeyt=
ab.patch, HADOOP-10158.patch, HADOOP-10158.patch, HADOOP-10158_multiplereal=
ms.patch, HADOOP-10158_multiplerealms.patch, HADOOP-10158_multiplerealms.pa=
tch
>
>
> This is the list of internal servlets added by namenode.
> | Name | Auth | Need to be accessible by end users |
> | StartupProgressServlet | none | no |
> | GetDelegationTokenServlet | internal SPNEGO | yes |
> | RenewDelegationTokenServlet | internal SPNEGO | yes |
> |  CancelDelegationTokenServlet | internal SPNEGO | yes |
> |  FsckServlet | internal SPNEGO | yes |
> |  GetImageServlet | internal SPNEGO | no |
> |  ListPathsServlet | token in query | yes |
> |  FileDataServlet | token in query | yes |
> |  FileChecksumServlets | token in query | yes |
> | ContentSummaryServlet | token in query | yes |
> GetDelegationTokenServlet, RenewDelegationTokenServlet, CancelDelegationT=
okenServlet and FsckServlet are accessed by end users, but hard-coded to us=
e the internal SPNEGO filter.
> If a name node HTTP server binds to multiple external IP addresses, the i=
nternal SPNEGO service principal name may not work with an address to which=
 end users are connecting.  The current SPNEGO implementation in Hadoop is =
limited to use a single service principal per filter.
> If the underlying hadoop kerberos authentication handler cannot easily be=
 modified, we can at least create a separate auth filter for the end-user f=
acing servlets so that their service principals can be independently config=
ured. If not defined, it should fall back to the current behavior.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)