Return-Path: X-Original-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 833709549 for ; Tue, 29 May 2012 22:34:26 +0000 (UTC) Received: (qmail 25158 invoked by uid 500); 29 May 2012 22:34:26 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 25129 invoked by uid 500); 29 May 2012 22:34:26 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-issues@hadoop.apache.org Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 25109 invoked by uid 99); 29 May 2012 22:34:26 -0000 Received: from issues-vm.apache.org (HELO issues-vm) (140.211.11.160) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 May 2012 22:34:26 +0000 Received: from isssues-vm.apache.org (localhost [127.0.0.1]) by issues-vm (Postfix) with ESMTP id 30D68142837 for ; Tue, 29 May 2012 22:34:26 +0000 (UTC) Date: Tue, 29 May 2012 22:34:26 +0000 (UTC) From: "Aaron T. Myers (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: <1449261475.13460.1338330866204.JavaMail.jiratomcat@issues-vm> In-Reply-To: <1807212488.4190.1337982923015.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Commented] (HDFS-3466) The SPNEGO filter for the NameNode should come out of the web keytab file MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HDFS-3466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285201#comment-13285201 ] Aaron T. Myers commented on HDFS-3466: -------------------------------------- bq. I still feel that this flexibility is good to have. The users would have to keep track of if any keytab was generated for a given principal to know when to use the '-norandkey' option. To me this makes it easier to manage keytabs and principals. They're still going to have to know to do this even with separate configuration options, since the user might try to export a new keytab for the HTTP/... principal without knowing that they've already done so for a different service. I don't see how having two separate configuration options makes things easier. ---- If we go forward with this, then I think we should not require the two separate configuration options. In the current patch, the user would have to set both DFS_NAMENODE_KEYTAB_FILE_KEY and DFS_WEB_AUTHENTICATION_KERBEROS_KEYTAB_KEY even if entries for both principals were contained in a single keytab. We should make NameNodeHttpServer try DFS_NAMENODE_KEYTAB_FILE_KEY first, and then fall back on trying DFS_WEB_AUTHENTICATION_KERBEROS_KEYTAB_KEY if the first one does not contain an entry for the appropriate principal. > The SPNEGO filter for the NameNode should come out of the web keytab file > ------------------------------------------------------------------------- > > Key: HDFS-3466 > URL: https://issues.apache.org/jira/browse/HDFS-3466 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node, security > Affects Versions: 1.1.0, 2.0.0-alpha > Reporter: Owen O'Malley > Assignee: Owen O'Malley > Attachments: hdfs-3466-b1.patch, hdfs-3466-trunk.patch > > > Currently, the spnego filter uses the DFS_NAMENODE_KEYTAB_FILE_KEY to find the keytab. It should use the DFS_WEB_AUTHENTICATION_KERBEROS_KEYTAB_KEY to do it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira