hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuanbo Liu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-13119) Web UI error accessing links which need authorization when Kerberos
Date Fri, 20 Jan 2017 07:11:26 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-13119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15831324#comment-15831324
] 

Yuanbo Liu commented on HADOOP-13119:
-------------------------------------

[~aw] Thanks for your response.
{quote}
I did a quick read through the...
{quote}
Sorry, the old discussion may be a little confusing here, so I'd like to clarify it at first.
When security is enabled in Hadoop, Knox cannot access "/logs", and adding user "knox" to
"dfs.cluster.administrators" seems to be the only way to let customer access the link by Knox.
As you mentioned above, the users in this group should almost certainly not be proxiable accounts,
which I agree with you. So we should extend the ability of http filter to support proxy user.
That means when user "sam" wants to access "/logs" of secure hadoop by Knox, we just need
to add "sam" to "dfs.cluster.administrators" and make user "knox" impersonate sam, user "knox"
responses to authentication requirement while user "sam" responses to authorization requirement.
In the end, user "sam" can access the link "/logs".
{quote}
 allow anyone to run as any other user
{quote}
The answer is absolutely no, this is not the purpose of this JIRA. I just want to extent the
function of SPNEGO filter and let it support impersonation.
{quote}
extremely limited circumstances why proxying might be necessary
{quote} 
When I dig it more, I find the filter chains in different Hadoop components are quite variable
and of course we want to uniform them. When comes to YARN or Job History Server, we want to
use SPENGO filter instead of delegation filter, which is clearly supported by Hadoop(We can
find the introduction in Hadoop docs), then the proxying becomes quite hot, because there're
a lot of application users in YARN. From the security perspective, when Knox accesses Yarn
application links, we don't want to have only one user "knox", and we need user "knox" impersonates
different users. So extending SPNEGO filter's function is needed.
Hope my rely can answer your doubts. Any further comment will be appreciated. Thanks a lot!

> Web UI error accessing links which need authorization when Kerberos
> -------------------------------------------------------------------
>
>                 Key: HADOOP-13119
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13119
>             Project: Hadoop Common
>          Issue Type: Bug
>    Affects Versions: 2.8.0, 2.7.4
>            Reporter: Jeffrey E  Rodriguez
>            Assignee: Yuanbo Liu
>              Labels: security
>         Attachments: HADOOP-13119.001.patch, HADOOP-13119.002.patch, HADOOP-13119.003.patch,
HADOOP-13119.004.patch, HADOOP-13119.005.patch, screenshot-1.png
>
>
> User Hadoop on secure mode.
> login as kdc user, kinit.
> start firefox and enable Kerberos
> access http://localhost:50070/logs/
> Get 403 authorization errors.
> only hdfs user could access logs.
> Would expect as a user to be able to web interface logs link.
> Same results if using curl:
> curl -v  --negotiate -u tester:  http://localhost:50070/logs/
>  HTTP/1.1 403 User tester is unauthorized to access this page.
> so:
> 1. either don't show links if hdfs user  is able to access.
> 2. provide mechanism to add users to web application realm.
> 3. note that we are pass authentication so the issue is authorization to /logs/
> suspect that /logs/ path is secure in webdescriptor so suspect users by default don't
have access to secure paths.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message