[
https://issues.apache.org/jira/browse/HADOOP-15996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729821#comment-16729821
]
Bolke de Bruin edited comment on HADOOP-15996 at 12/27/18 8:00 PM:
-------------------------------------------------------------------
[[email protected]]
The issue is that Hadoop is in compatible mode not even entirely MIT. In MIT
(and also Heimdal) you cannot match an arbitrary realm and you need to
configure them explicitly. This way you cannot end up transforming users from
FOO to local user names just because you had a rule nullifying *any* realm.
Obviously it guards against user mistakes and is more secure. This is how it
works in MIT.
{code:java}
EXAMPLE.COM = {
kdc = localhost:_KDC_PORT_
auth_to_local = {
RULE:[2:$1](johndoe)s/^.*$/guest/
RULE:[2:$1;$2](^.*;admin$)s/;admin$//
RULE:[2:$2](root)
DEFAULT
}
}
YAHOO.COM = {
auth_to_local = {
RULE:[1:$1@$0](.*@YAHOO\\.COM)s/@.*//
}
} {code}
In Hadoop you can mix those.
{code:java}
auth_to_local = RULE:[2:$1](johndoe)s/^.*$/guest/
RULE:[2:$1;$2](^.*;admin$)s/;admin$//
RULE:[1:$1@$0](.*@YAHOO\\.COM)s/@.*//
RULE:[2:$2](root)
DEFAULT{code}
Hence why it is called compatible. I'm working on a "system" version that takes
krb5.conf and does fully adhere to MIT rules.
I'm fine with using "compatible".
*Verbosity*
I'm a bit in doubt here. Obviously it can log quite often on the other hand
forcing the user to make an explicit choice is probably good here. Also, the
'legacy' version is logging an *error* on every non simple name (equal to the
current state after the revert). What do you suggest?
*Check on incorrect setting*
Good point, I'll add some validation.
was (Author: bolke):
[[email protected]]
The issue is that Hadoop is in compatible mode not even entirely MIT. In MIT
(and also Heimdal) you cannot match an arbitrary realm and you need to
configure them explicitly. This way you cannot end up transforming users from
FOO to local user names just because you had a rule nullifying *any* realm.
Obviously it guards against user mistakes and is more secure. This is how it
works in MIT.
{code:java}
EXAMPLE.COM = {
kdc = localhost:_KDC_PORT_
auth_to_local = {
RULE:[2:$1](johndoe)s/^.*$/guest/
RULE:[2:$1;$2](^.*;admin$)s/;admin$//
RULE:[2:$2](root)
DEFAULT
}
}
YAHOO.COM = {
auth_to_local = {
RULE:[1:$1@$0](.*@YAHOO\\.COM)s/@.*//
}
} {code}
In Hadoop you can mix those:auth_to_local =
{code:java}
RULE:[2:$1](johndoe)s/^.*$/guest/
RULE:[2:$1;$2](^.*;admin$)s/;admin$//
RULE:[1:$1@$0](.*@YAHOO\\.COM)s/@.*//
RULE:[2:$2](root)
DEFAULT{code}
Hence why it is called compatible. I'm working on a "system" version that takes
krb5.conf and does fully adhere to MIT rules.
I'm fine with using "compatible".
> 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]
