accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-4421) TraceServer should fall back to GENERIC_KERBEROS_PRINCIPAL when trace specific kerberos settings are not present
Date Fri, 26 Aug 2016 14:29:20 GMT


Josh Elser commented on ACCUMULO-4421:

Thanks for catching this, Sean! I had it in my mind that the Tracer using the new authentication
mechanism (despite still being over Kerberos) would be a completely separate configuration
setup and didn't think about the side-effects.

bq.  3) if there is a trace-specific or general keytab, we get the TRACE_USER (without any
_HOST expansion, presumably UGI does this for us?) and try to log in.

Yes, I believe so.

bq.  4) on just the tracer, we use some UGI side effect to do the renewal thread. on others
we start our own?

This should be done via {{SecurityUtil#startTicketRenewalThread(..)}}. UGI's will only happen
if there's an existing ticket cache (not via keytab login).

bq. which happened in #3 above and presumably we assume downstream applications would do their
own UGI logins (is there a reason the UGI / Login stuff can't happen in the KerberosToken

Yeah, there is. Our API doesn't presently lend itself well to not stomping on multiple identities
presently. One place I ran into this was in Replication with Kerberos authentication. If the
KerberosToken is doing a login, it could unintentionally log out the TabletServer and break
things. We could do this a little better by refactoring the implementation (in the token and
the API) so that all API calls are passed through the Token (to allow for a doAs() by the
Token implementation).

bq. (does this break things if SASL isn’t using GSSAPI? should this be checking the TRACE_TOKEN_TYPE
instead of the rpc sasl, or maybe in addition to it?)

Having the Tracer interact with Accumulo over SASL using any other mechanism than GSSAPI is
out of scope. The only intended time for non-GSSAPI mechanism is via DelegationTokens (falling
back to DIGEST). We had talked about moving the present username/password auth over to DIGEST
and using SASL all of the time, but I think this isn't a big concern ATM.

bq. If I change this to check for TRACE_TOKEN_TYPE as kerberos prior to selecting the TRACE_USER
instead of GENERIC_KERBEROS_PRINCIPAL I think this will be operationally compatible for folks
already relying on the current behavior.

This sounds good. I'll try to dig through the code and verify some of this.

> TraceServer should fall back to GENERIC_KERBEROS_PRINCIPAL when trace specific kerberos
settings are not present
> ----------------------------------------------------------------------------------------------------------------
>                 Key: ACCUMULO-4421
>                 URL:
>             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 keytab isn't specified
for the trace user, but it will simply exit early if there isn't a principal defined for hte
trace user. It should instead default to the GENERIC_KERBEROS_PRINCIPAL.

This message was sent by Atlassian JIRA

View raw message