[
https://issues.apache.org/jira/browse/HADOOP-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13602271#comment-13602271
]
Daryn Sharp commented on HADOOP-9299:
-------------------------------------
bq. In UGI, the skip check should be kept, else it will break things for things
using hadoop-auth which don't use hadoop config files in their classpath.
I think in those cases the defaults will kick in, which is the behavior we'd
want? Or is there a quirk that will cause problems?
bq. Unless I'm missing something, we are using the Kerberos principal short
name when interacting with an unsecure cluster, that seems wrong, no?
Please elaborate? Overall, I don't believe this patch causes any fundamental
change in behavior - other than making insecure clients/servers be able to
perform simple reduction of a principal in the absence of explicit rules. A
few observations:
* Within the UGI, the short name appears to be computed in the ctor for use as
a key in the group name cache. That's typically not required on the
client-side. External to the UGI usage should experience no change in
behavior. In either case, I don't think new issues have been introduced?
* An IPC connection will (already) pass the full principal in the connection
context. It's up to the insecure server to reduce the principal to a short
name. I haven't tested, but w/o this patch, I think an insecure server will
choke on the kerberos principal unless configured with rules.
* The token operations do already inconsistently pass a short name or principal
for the various fields. Now that's wrong, and should always be the full
principal, but it's a separate issue to fix.
Is there somewhere that I've made something "worse"? Or are you referring to
pre-existing issues that should be addressed on another jira?
> kerberos name resolution is kicking in even when kerberos is not configured
> ---------------------------------------------------------------------------
>
> Key: HADOOP-9299
> URL: https://issues.apache.org/jira/browse/HADOOP-9299
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 2.0.3-alpha
> Reporter: Roman Shaposhnik
> Assignee: Daryn Sharp
> Priority: Blocker
> Attachments: HADOOP-9299.patch
>
>
> Here's what I'm observing on a fully distributed cluster deployed via Bigtop
> from the RC0 2.0.3-alpha tarball:
> {noformat}
> 528077-oozie-tucu-W@mr-node] Error starting action [mr-node]. ErrorType
> [TRANSIENT], ErrorCode [JA009], Message [JA009:
> org.apache.hadoop.security.authentication.util.KerberosName$NoMatchingRule:
> No rules applied to yarn/localhost@LOCALREALM
> at
> org.apache.hadoop.security.token.delegation.AbstractDelegationTokenIdentifier.<init>(AbstractDelegationTokenIdentifier.java:68)
> at
> org.apache.hadoop.mapreduce.v2.api.MRDelegationTokenIdentifier.<init>(MRDelegationTokenIdentifier.java:51)
> at
> org.apache.hadoop.mapreduce.v2.hs.HistoryClientService$HSClientProtocolHandler.getDelegationToken(HistoryClientService.java:336)
> at
> org.apache.hadoop.mapreduce.v2.api.impl.pb.service.MRClientProtocolPBServiceImpl.getDelegationToken(MRClientProtocolPBServiceImpl.java:210)
> at
> org.apache.hadoop.yarn.proto.MRClientProtocol$MRClientProtocolService$2.callBlockingMethod(MRClientProtocol.java:240)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:454)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1014)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1735)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1731)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:396)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1441)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1729)
> Caused by:
> org.apache.hadoop.security.authentication.util.KerberosName$NoMatchingRule:
> No rules applied to yarn/localhost@LOCALREALM
> at
> org.apache.hadoop.security.authentication.util.KerberosName.getShortName(KerberosName.java:378)
> at
> org.apache.hadoop.security.token.delegation.AbstractDelegationTokenIdentifier.<init>(AbstractDelegationTokenIdentifier.java:66)
> ... 12 more
> ]
> {noformat}
> This is submitting a mapreduce job via Oozie 3.3.1. The reason I think this
> is a Hadoop issue rather than the oozie one is because when I hack
> /etc/krb5.conf to be:
> {noformat}
> [libdefaults]
> ticket_lifetime = 600
> default_realm = LOCALHOST
> default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
> default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
> [realms]
> LOCALHOST = {
> kdc = localhost:88
> default_domain = .local
> }
> [domain_realm]
> .local = LOCALHOST
> [logging]
> kdc = FILE:/var/log/krb5kdc.log
> admin_server = FILE:/var/log/kadmin.log
> default = FILE:/var/log/krb5lib.log
> {noformat}
> The issue goes away.
> Now, once again -- the kerberos auth is NOT configured for Hadoop, hence it
> should NOT pay attention to /etc/krb5.conf to begin with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
