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

Vrushali C commented on YARN-6820:
----------------------------------

Thanks [~jlowe]
bq.  don't see why we would sometimes want to get the user via the principal 
and sometimes not
Yes, I was initially using getRemoteUser since the webservices in timeline 
service are invoking that. But the RM webservices seem to be using the 
getUserPrincipal.

I looked up in the Java EE documentations for 6 and 7 regarding the behavior 
around getRemoteUser and getUserPrincipal. 

http://docs.oracle.com/javaee/6/tutorial/doc/gjiie.html#bncba

https://docs.oracle.com/javaee/7/tutorial/security-webtier003.htm

Both 6 and 7 seem to say the same thing:

{code}
getRemoteUser, which determines the user name with which the client 
authenticated. The getRemoteUser method returns the name of the remote user 
(the caller) associated by the container with the request. If no user has been 
authenticated, this method returns null.

getUserPrincipal, which determines the principal name of the current user and 
returns a java.security.Principal object. If no user has been authenticated, 
this method returns null. Calling the getName method on the Principal returned 
by getUserPrincipal returns the name of the remote user.
{code}

It looks like getUserPrincipal.getName will get the name of the remote user, so 
I think both calls that timeline service is making, will return the same thing. 
That said, I can still file a jira to ensure the webservices code (unrelated to 
this patch) will invoke the getUserPrincipal so that we have consistency across 
the codebase.  What do you think? 





> Restrict read access to timelineservice v2 data 
> ------------------------------------------------
>
>                 Key: YARN-6820
>                 URL: https://issues.apache.org/jira/browse/YARN-6820
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Vrushali C
>            Assignee: Vrushali C
>              Labels: yarn-5355-merge-blocker
>         Attachments: YARN-6820-YARN-5355.0001.patch, 
> YARN-6820-YARN-5355.002.patch, YARN-6820-YARN-5355.003.patch, 
> YARN-6820-YARN-5355.004.patch, YARN-6820-YARN-5355.005.patch
>
>
> Need to provide a way to restrict read access in ATSv2. Not all users should 
> be able to read all entities. On the flip side, some folks may not need any 
> read restrictions, so we need to provide a way to disable this access 
> restriction as well. 
> Initially this access restriction could be done in a simple way via a 
> whitelist of users allowed to read data. That set of users can read all data, 
> no other user can read any data. Can be turned off for all users to read all 
> data.
> Could be stored in a "domain" table in hbase perhaps. Or a configuration 
> setting for the cluster. Or something else that's simple enough. ATSv1 has a 
> concept of domain for isolating users for reading. Would be good to keep that 
> in consideration. 
> In ATSv1, domain offers a namespace for Timeline server allowing users to 
> host multiple entities, isolating them from other users and applications. A 
> “Domain” in ATSV1 primarily stores owner info, read and& write ACL 
> information, created and modified time stamp information. Each Domain is 
> identified by an ID which must be unique across all users in the YARN cluster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org

Reply via email to