hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-6946) SecurityUtils' TGT fetching does not fall back to "login" user
Date Thu, 06 Jan 2011 01:57:47 GMT

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

Todd Lipcon commented on HADOOP-6946:
-------------------------------------

bq. in fetchServiceTicket doesn't the same subject from getTgtFromSubject need to be used
when adding private credentials? ie won't the subject be null there as well if it's null in
the current version of getTgtFromSubject?

Not sure I follow. In fetchServiceTicket, after the patch, we use getTgtFromSubject - which
now goes to {{UGI.getCurrentUser().getSubject()}} - and then add the new ticket to the same
place in the last line of this function.

bq. need to update the javadoc to remove that the IOException is no longer thrown

Where do you mean? UGI.getCurrentUser() throws IOE, so the functions both still throw IOE
like they used to.

> SecurityUtils' TGT fetching does not fall back to "login" user
> --------------------------------------------------------------
>
>                 Key: HADOOP-6946
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6946
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 0.22.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>         Attachments: hadoop-6946-20security.txt, hadoop-6946.txt
>
>
> In SecurityUtil.getTgtFromSubject and SecurityUtil.fetchServiceTicket, the current JAAS
Subject is fetched directly from the AccessController, rather than using UserGroupInformation.getCurrentUser().getSubject().
This means that if it is not run in the confines of a doAs() block, it will fail since the
current JAAS subject is null, even though SecurityUtil.login(...) may have been called.
> In practice, one place this shows up is using the secondary namenode's "-checkpoint force"
option in secured 0.20, since it's done inside the main thread with no surrounding doAs().

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message