[
https://issues.apache.org/jira/browse/YARN-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334907#comment-16334907
]
Jason Lowe commented on YARN-3895:
----------------------------------
{quote}
So, we store these kind of doAs query related entities in a table called subApp
table. The rowkey in this table contains both the subAppUserId as well as the
AM user ID. Although we do not check if the AM is allowed to write as some
user, the entity for this pair of {AM user, subAppUser ID } will be in it’s own
row. The row key also has the cluster id, entity type, entity id and entity id
prefix.
{quote}
I think that's reasonable. One user shouldn't be able to doctor the data of
another, and it sounds like this will prevent that.
bq. With every timeline entity, we propose to have a TimelineEntityACLs object
inside it.
My concern here would be the size of the TimelineEntityACLs object. If that
object is itself fully definitive of the ACLs without referencing some other
authoritative object (i.e.: like the domain IDs did in ATS 1), then I could see
cases where the ACLs are not that small, potentially larger than an average
entity. Just as that would be cumbersome to store per cell, it would be
cumbersome to build and parse per entity. Having a tidy ID to reference a set
of ACLs would eliminate this concern, but it would add some necessary
indirection lookups on the reader side.
> Support ACLs in ATSv2
> ---------------------
>
> Key: YARN-3895
> URL: https://issues.apache.org/jira/browse/YARN-3895
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Affects Versions: YARN-2928
> Reporter: Varun Saxena
> Assignee: Varun Saxena
> Priority: Major
> Labels: YARN-5355
>
> This JIRA is to keep track of authorization support design discussions for
> both readers and collectors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
