[
https://issues.apache.org/jira/browse/HADOOP-15996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729950#comment-16729950
]
Eric Yang commented on HADOOP-15996:
------------------------------------
[[email protected]] {quote}If someone is running a cluster and hasn't set a
policy, is every single one of their apps going to be adding a log message
telling them off? And how many times per app?{quote}
The warning message should not happen unless the user application has somehow
created the KerberosName object without core-default.xml in the classpath.
It's guarding against code running in custom environment that may not have
Hadoop configuration object initialized in the expected order. This should not
happen in Hadoop itself, but it could be possible if third party application
does things differently than Hadoop.
[~lmccay] {quote}I don't understand the explanation of the compatibility name
as it seems that you are saying it isn't really compatible with anything.{quote}
Compatible mode is referring to how auth_to_local rule works that is compatible
with MIT kerberos as a utility function. Legacy mode represents Hadoop
original implementation using auth_to_local as firewall rules. The naming only
make sense to people that can distinguish the semantic difference between
legacy Hadoop Kerberos auth_to_local and MIT Kerberos auth_to_local
definitions. This is not multi-realm specific, and calling it multi-realm
specific flag may create more confusion from the intend of using auth_to_local
as firewall rules or not.
"system" mode is also proposed to use auth_to_local rules directly from
krb5.conf. Rule mechanism types are important to show the clarity of the
modes. Maybe we can call it, "passive" = compat, "enforce" = legacy, "os" =
system to make this easier to discern the different types?
> Plugin interface to support more complex usernames in Hadoop
> ------------------------------------------------------------
>
> Key: HADOOP-15996
> URL: https://issues.apache.org/jira/browse/HADOOP-15996
> Project: Hadoop Common
> Issue Type: New Feature
> Components: security
> Reporter: Eric Yang
> Assignee: Bolke de Bruin
> Priority: Major
> Attachments: 0001-HADOOP-15996-Make-auth-to-local-configurable.patch,
> 0001-Make-allowing-or-configurable.patch,
> 0001-Simple-trial-of-using-krb5.conf-for-auth_to_local-ru.patch,
> 0002-HADOOP-15996-Make-auth-to-local-configurable.patch,
> 0003-HADOOP-15996-Make-auth-to-local-configurable.patch,
> 0004-HADOOP-15996-Make-auth-to-local-configurable.patch,
> 0005-HADOOP-15996-Make-auth-to-local-configurable.patch,
> HADOOP-15996.0005.patch, HADOOP-15996.0006.patch
>
>
> Hadoop does not allow support of @ character in username in recent security
> mailing list vote to revert HADOOP-12751. Hadoop auth_to_local rule must
> match to authorize user to login to Hadoop cluster. This design does not
> work well in multi-realm environment where identical username between two
> realms do not map to the same user. There is also possibility that lossy
> regex can incorrectly map users. In the interest of supporting multi-realms,
> it maybe preferred to pass principal name without rewrite to uniquely
> distinguish users. This jira is to revisit if Hadoop can support full
> principal names without rewrite and provide a plugin to override Hadoop's
> default implementation of auth_to_local for multi-realm use case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
