[
https://issues.apache.org/jira/browse/HADOOP-15996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730589#comment-16730589
]
Bolke de Bruin edited comment on HADOOP-15996 at 12/29/18 10:09 AM:
--------------------------------------------------------------------
[~lmccay]
{quote}[~bolke] - then make the names be what they are. Compat is just not
meaningful. Make it DEFAULT and MIT or HADOOP and MIT- OS for system makes
sense or SYSTEM would work too. Again, the semantic differences need to be
articulated and documented very clearly.
{quote}
-I'll go for "hadoop", "MIT_like", "system" (if that is ok). MIT_like as it
better covers that Hadoop still does deviate from MIT.-
I'll go for "Hadoop", "MIT", "system". I just double checked and MIT actually
does allow foreign realms inside the another realms specification. It depends
on the kerberos context of the authentication which one it chooses. Hadoop
always assumes default realm.
{quote}There is no reason to print a warning for the default mechanism being
used but folks do need to be able to determine what the default semantics are
easily.
{quote}
Warning will be removed from HadoopKerberosName (next version of patch). I'd
like to keep a 'null' check. It should only turn up when people make use of
KerberosName directly and makes debugging for us and for the user easier. I
actually spent quite some time on this patch (see above) as I did not use a
null check earlier and there was not enough direct debug information available
to pin point the issue.
[[email protected]]
{quote}TestUserGroupInformation
{quote}
*
{quote}keep with the static imports of specific fields, given someone has
started that way
{quote} *
{quote}{{testConstructorFailures}}. If the exception doesn't match, rethrow the
full exception, possibly as the cause of a raised assertion. Preserves the
stack trace.
{quote}
Will do.
was (Author: bolke):
[~lmccay]
{quote}[~bolke] - then make the names be what they are. Compat is just not
meaningful. Make it DEFAULT and MIT or HADOOP and MIT- OS for system makes
sense or SYSTEM would work too. Again, the semantic differences need to be
articulated and documented very clearly.
{quote}
I'll go for "hadoop", "MIT_like", "system" (if that is ok). MIT_like as it
better covers that Hadoop still does deviate from MIT.
{quote}There is no reason to print a warning for the default mechanism being
used but folks do need to be able to determine what the default semantics are
easily.
{quote}
Warning will be removed from HadoopKerberosName (next version of patch). I'd
like to keep a 'null' check. It should only turn up when people make use of
KerberosName directly and makes debugging for us and for the user easier. I
actually spent quite some time on this patch (see above) as I did not use a
null check earlier and there was not enough direct debug information available
to pin point the issue.
[[email protected]]
{quote}TestUserGroupInformation
{quote} *
{quote}keep with the static imports of specific fields, given someone has
started that way{quote}
*
{quote}{{testConstructorFailures}}. If the exception doesn't match, rethrow the
full exception, possibly as the cause of a raised assertion. Preserves the
stack trace.{quote}
Will do.
> 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]
