Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 25 Aug 2016 05:17:20 +0000 (UTC)
From: "Sean Busbey (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12999664.1472046150000.405683.1472102240537@Atlassian.JIRA>
In-Reply-To: <JIRA.12999664.1472046150000@Atlassian.JIRA>
References: <JIRA.12999664.1472046150000@Atlassian.JIRA> <JIRA.12999664.1472046150165@arcas>
Subject: [jira] [Commented] (ACCUMULO-4421) TraceServer should fall back to
 GENERIC_KERBEROS_PRINCIPAL when trace specific kerberos settings are not
 present
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 25 Aug 2016 05:17:22 -0000


    [ https://issues.apache.org/jira/browse/ACCUMULO-4421?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1=
5436301#comment-15436301 ]=20

Sean Busbey commented on ACCUMULO-4421:
---------------------------------------

Digging into this, a run through of what happens with some questions

1) we have a means to say how authentication for the tracer should happen, =
TRACE_TOKEN_TYPE, which defaults to user/pass and our instructions say to c=
hange to KerberosToken when Accumulo is using Kerberos to handle clients
2) on service start, we look for kerberos configs and  ignore TRACE_TOKEN_T=
YPE
3) if there is a trace-specific or general keytab, we get the TRACE_USER (w=
ithout any _HOST expansion, presumably UGI does this for us?) and try to lo=
g in.
4) on just the tracer, we use some UGI side effect to do the renewal thread=
. on others we start our own?
5) On TraceServer object init, we check if we have the default TRACE_TOKEN_=
TYPE and then look for TRACE_USER and (after a fashion) TRACE_PASSWORD=20
6) For non-default TRACE_TOKEN_TYPE (like KerberosToken), then we rely on c=
reation via reflection of the class and a call to init. KerberosToken is es=
sentially a no-op for =E2=80=9Cthere is a logged in kerberos user=E2=80=9D,=
 which happened in #3 above and presumably we assume downstream application=
s would do their own UGI logins (is there a reason the UGI / Login stuff ca=
n't happen in the KerberosToken itself?)
7) If RPC SASL is on, we do _HOST substitution in TRACE_USER before opening=
 our connection; I presume so it will match the user identified in the Kerb=
erosToken. (does this break things if SASL isn=E2=80=99t using GSSAPI? shou=
ld this be checking the TRACE_TOKEN_TYPE instead of the rpc sasl, or maybe =
in addition to it?)

I think #2 above is the source of my problem, since I have Kerberos on for =
services like HDFS, but not for Accumulo clients (e.g. as a step in upgradi=
ng Accumulo from 1.6 on a secure HDFS cluster prior to rolling out kerberos=
 for accumulo clients).

If I change this to check for TRACE_TOKEN_TYPE as kerberos prior to selecti=
ng the TRACE_USER instead of GENERIC_KERBEROS_PRINCIPAL I *think* this will=
 be operationally compatible for folks already relying on the current behav=
ior.

> TraceServer should fall back to GENERIC_KERBEROS_PRINCIPAL when trace spe=
cific kerberos settings are not present
> -------------------------------------------------------------------------=
---------------------------------------
>
>                 Key: ACCUMULO-4421
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4421
>             Project: Accumulo
>          Issue Type: Bug
>          Components: trace
>    Affects Versions: 1.7.1, 1.7.2
>            Reporter: Sean Busbey
>            Assignee: Sean Busbey
>            Priority: Blocker
>             Fix For: 1.8.0
>
>         Attachments: ACCUMULO-4421.1.patch
>
>
> Prior to 1.7, the TraceServer always started using the same server utils =
as the other daemons. Since a trace server has to talk to Accumulo and that=
 might involve needing a Kerberos Identity in 1.7+, it was switched to its =
own setup.
> Currently that setup will default back to GENERIC_KERBEROS_KEYTAB if a ke=
ytab isn't specified for the trace user, but it will simply exit early if t=
here isn't a principal defined for hte trace user. It should instead defaul=
t to the GENERIC_KERBEROS_PRINCIPAL.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)