[
https://issues.apache.org/jira/browse/HADOOP-15996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729855#comment-16729855
]
Larry McCay commented on HADOOP-15996:
--------------------------------------
I don't understand the explanation of the compatibility name as it seems that
you are saying it isn't really compatible with anything. :)
I did have the same question when I was initially looking at the patch but have
kept quiet as I was waiting for a patch that worked.
The code still has comments indicating that it is following MIT rules. COMPAT
doesn't mean anything. Again, we need to make sure that we clearly articulate
what the "legacy" and "compat" behavior differences are. Otherwise, folks won't
know why to choose one over the other.
I actually don't like that there are warnings about the default being chosen.
The default behavior should be what it always was and only be overridden by an
admin explicitly choosing the other.
So, I would say the following should be addressed:
# Names: "Legacy" implies that it has been replaced by something new. This
isn't the case, there is another option to choose and a default. DEFAULT would
make sense. "Compat" doesn't mean anything since it isn't fully compatible with
any particular thing and really cannot be documented in a way that makes that
name meanful. My understanding is that this is an option that was added to
accommodate multi-tenancy better. If MIT or MIT-VARIANT doesn't work then make
it a name related to its need - MULTI_TENANT or something like that. I lean
towards that since it is more easily documented than how it is compatible but
not exactly compatible with MIT rules.
# The following should be changed to not be null by default but DEFAULT and
remove all the checks and warnings for it being null.{code}
+ /**
+ * How to evaluate auth_to_local rules + */
+ private static String ruleMechanism = null;
{code}
# There appear to be checkstyle and whitespace violations added by the patch
> 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: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
