[
https://issues.apache.org/jira/browse/HADOOP-15162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317395#comment-16317395
]
Daryn Sharp commented on HADOOP-15162:
--------------------------------------
bq. This has been known issues with SIMPLE security since Hadoop 0.20s release.
The words simple and security don't belong in the same sentence, but let's
discuss anyway.
bq. createRemoteUser should be intelligent to know the preference of the
authentication to apply to avoid security holes
No. The createRemoteUser method works as designed. App-specific control logic
does not belong in the ugi. A new ugi has only a presumed identity. It's up
to the app code to either fill it with credentials or attach a real user (via
createProxyUser) that has credentials and proxy privs.
Based on the snippets of code that conclude with "if authentication are in
place, server side code can be simplified to \[...\]
UserGroupInformation.createRemoteUser(remoteUser);", _I think_ you are
suggesting that createRemote should auto-magically create a proxy user with the
login user? If you say yes, I'll provide a litany of reasons why that'd be
completely broken. If no, please more concisely state your use case.
bq. Client code can assign any arbitrary user, and trigger authentication
challenge to occur when communicate with the server side. This is happening
when Kerberos security is enabled. It would be nice if the same practice can
apply to SIMPLE security without open up security holes regardless Kerberos
security is enabled or not.
If security is disabled, how can the phrases "trigger authentication" and
"without open security holes" have any meaning?
bq. This left SIMPLE security to be completely open, no security and no proxy
check.
Based on the code snippets, I think you are alarmed that an insecure client can
decide to not create a proxy user, thus bypassing an insecure server's proxy
checks for originating user/host. While one of my long held pet peeves is
client code should never be conditionalized for "security enabled", it's
impossible for an insecure server to know whether an insecure client is
honestly reporting whether it's a proxy user.
> UserGroupInformation.createRemoteUser hardcode authentication method to SIMPLE
> ------------------------------------------------------------------------------
>
> Key: HADOOP-15162
> URL: https://issues.apache.org/jira/browse/HADOOP-15162
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Reporter: Eric Yang
>
> {{UserGroupInformation.createRemoteUser(String user)}} is hard coded
> Authentication method to SIMPLE by HADOOP-10683. This by passed proxyuser
> ACL check, isSecurityEnabled check, and allow caller to impersonate as
> anyone. This method could be abused in the main code base, which can cause
> part of Hadoop to become insecure without proxyuser check for both SIMPLE or
> Kerberos enabled environment.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
