[
https://issues.apache.org/jira/browse/HADOOP-13081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536658#comment-15536658
]
Daryn Sharp commented on HADOOP-13081:
--------------------------------------
Restoring a new & broken API because it shipped in an alpha isn't a good reason
to put it back. Nothing in an alpha is supposed to carry any guarantee of
delivery in a final release. Not only is the implementation broken, but it's
very dangerous for inexperienced developers.
bq. the concrete use case is where a service runs multiple pieces of work on
behalf of users; it can be set to log in as a particular user using Kerberos
(specifically when running these), but the users can also add their own tokens.
Why isn't a proxy user insufficient? Let's explore your use case:
# Kerberos login as superman
# Clone the UGI
# Add tokens for daryn
# Access remote services for which no token is available, or the token was
added incorrectly - oops, I'm superman to that service
# Traverse a symlink from NN1 to NN2, oops, now I'm superman on NN2
If you are running a secure cluster, then why would you possibly risk exposing
yourself to privilege escalation?
With proxy users I will never be superman. Period. The real user may
authenticate, but I'll never be the real user.
# Kerberos login as superman
# Create proxy UGI for daryn. It's a wrapper over the superman ugi, other
proxy users share the common ugi. No multiple logins.
# Add tokens to the proxy ugi
# Access any remote services - I will be the user in a token, or superman will
kerberos auth and request an authz to be daryn. Unless the service is
configured to allow superman to be me, the connection is rejected.
> add the ability to create multiple UGIs/subjects from one kerberos login
> ------------------------------------------------------------------------
>
> Key: HADOOP-13081
> URL: https://issues.apache.org/jira/browse/HADOOP-13081
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Fix For: 2.8.0, 3.0.0-alpha1
>
> Attachments: HADOOP-13081.01.patch, HADOOP-13081.02.patch,
> HADOOP-13081.02.patch, HADOOP-13081.03.patch, HADOOP-13081.03.patch,
> HADOOP-13081.patch
>
>
> We have a scenario where we log in with kerberos as a certain user for some
> tasks, but also want to add tokens to the resulting UGI that would be
> specific to each task. We don't want to authenticate with kerberos for every
> task.
> I am not sure how this can be accomplished with the existing UGI interface.
> Perhaps some clone method would be helpful, similar to createProxyUser minus
> the proxy stuff; or it could just relogin anew from ticket cache.
> getUGIFromTicketCache seems like the best option in existing code, but there
> doesn't appear to be a consistent way of handling ticket cache location - the
> above method, that I only see called in test, is using a config setting that
> is not used anywhere else, and the env variable for the location that is used
> in the main ticket cache related methods is not set uniformly on all paths -
> therefore, trying to find the correct ticket cache and passing it via the
> config setting to getUGIFromTicketCache seems even hackier than doing the
> clone via reflection ;) Moreover, getUGIFromTicketCache ignores the user
> parameter on the main path - it logs a warning for multiple principals and
> then logs in with first available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
