Allen Wittenauer Thanks for your response.
I did a quick read through the...
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".
allow anyone to run as any other user
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.
extremely limited circumstances why proxying might be necessary
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!