hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunil Govind <sunil.gov...@gmail.com>
Subject Re: Queue ACLs overridden by yarn.admin.acl
Date Fri, 01 Jul 2016 08:10:52 GMT
Hi Prabhu

If  "yarn.admin.acl" is configured with "yarn", then "yarn" user can be
used to administer apps in cluster generally. This is handled as per admin
ACLs. Similarly CS also have Queue ACLs, and these ACLs can be set per
queue level.

So as per you example (with some minor changes)
yarn.admin.acl yarn
yarn.acl.enable true


Users "yarn" and "x" can have administer access in queue "test". Other
users now cannot access apps submitted from "yarn" and "x" user.

It seems like, you are looking for a read-only user who can view all apps
in a queue/queues from UI or from cli. As I see it, we do not have such an
option yet, and seems like you are looking for "acl_view_applications"
mode. This comes with a complexity as we need clear separation in client
apis (read-only vs read-write) for VIEW ACLs. Thoughts?


On Thu, Jun 30, 2016 at 11:21 PM Prabhu Joseph <prabhujose.gates@gmail.com>

> Hi All,
>     On Hadoop-2.7.1, Yarn CapaictyScheduler, a x user can kill the job
> submitted by yarn user even though the x user does not have administer acl
> on the queue. The queue -showacls does not show ADMINISTER_QUEUE on that
> queue for x user but since yarn.admin.acl is *, it allows x to kill the
> job. If we set yarn.admin.acl as yarn, then it works fine but which won't
> allow all users to view all jobs in RM UI for secure cluster. So, how to
> restrict some x user from killing other user job with yarn.admin.acl as *.
> yarn.admin.acl *
> yarn.acl.enable true
> yarn.scheduler.capacity.root.test.acl_administer_queue=yarn,
> yarn.scheduler.capacity.root.test.acl_submit_applications=*
> yarn.scheduler.capacity.root.acl_administer_queue=yarn,
> yarn.scheduler.capacity.root.acl_submit_applications=*
> [x@spark3 root]$ hadoop queue -showacls
> Queue acls for user :  x
> Queue  Operations
> =====================
> Thanks,
> Prabhu Joseph

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message