> On March 4, 2014, 9:29 a.m., Niklas Nielsen wrote:
> > include/mesos/mesos.proto, lines 481-485
> > <https://reviews.apache.org/r/18730/diff/2/?file=509427#file509427line481>
> >
> > ACL implies a mapping from principal/user to a specific permission.
> > More advanced ACLs can eventually be useful (for example controlling
> > visibility between frameworks e.g. in end-points/webui). But it seems more
> > appropriate to use a term like "principal-map" here or introduce a field
> > which describes the permission that it grants. Here it is implicitly
> > allowing 1) A principal can use resources from role X 2) A principal can su
> > to user Y. Does that make sense? :)
>
> Adam B wrote:
> Agreed. We'll definitely want more fine-grained access control later. We
> could either use the standard ACL structure of {subject, action, resource}
> (e.g. {principal, impersonates, user}) and also allow a mapping from
> principal/user to group/role (expressable as {user, memberOf, group} or as
> attributes); or we can eschew ACLs in favor of Role-based access control
> (RBAC), which uses {subject -> roles} and {role: (permit/deny) operation}
> mappings.
> If we must move forward with the ACL{principal, users, roles} model, I
> would rename 'principal' to 'subject', since principal is more of an
> authentication term, not an ACL term; and I would clarify 'users' as
> 'impersonatableUsers' to indicate what we're doing to those users.
We can also use a {subject, action, object} structure. I.e., {"user", "can
access endpoint", "master-state"}, or {"principal", "can launch tasks as",
"user"}.
- Dominic
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18730/#review36117
-----------------------------------------------------------
On March 4, 2014, 3:27 p.m., Vinod Kone wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18730/
> -----------------------------------------------------------
>
> (Updated March 4, 2014, 3:27 p.m.)
>
>
> Review request for mesos, Adam B, Benjamin Hindman, and Niklas Nielsen.
>
>
> Bugs: MESOS-911
> https://issues.apache.org/jira/browse/MESOS-911
>
>
> Repository: mesos-git
>
>
> Description
> -------
>
> See summary.
>
>
> Diffs
> -----
>
> include/mesos/mesos.proto 37f8a7fcd23d467b1274c46c405b836510afbd49
> src/Makefile.am 61d832b89132be2cc5b8ae9bbf743685464f78a4
> src/authorizer/authorizer.hpp PRE-CREATION
> src/tests/authorization_tests.cpp PRE-CREATION
> src/tests/master_contender_detector_tests.cpp
> 8da7420e18c7a960b566fae13a5975857eb777ee
>
> Diff: https://reviews.apache.org/r/18730/diff/
>
>
> Testing
> -------
>
> make check
>
>
> Thanks,
>
> Vinod Kone
>
>
