> 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? :)
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.
> On March 4, 2014, 9:29 a.m., Niklas Nielsen wrote:
> > src/authorizer/authorizer.hpp, line 130
> > <https://reviews.apache.org/r/18730/diff/2/?file=509429#file509429line130>
> >
> > Should we be able to specify default behavior i.e. block all principals
> > that isn't mapped or only enforce mappings present and otherwise allow
> > anything?
> > Also, like the isolators. We should maybe plan for specifying the
> > authorizer to use; we can start by having it default to "local" which use
> > the json file.
Re: default behavior: Or we can let default principal '*' have ACL {*,
defaultAction, defaultResources} or RBAC {* -> defaultRole}.
- Adam
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18730/#review36117
-----------------------------------------------------------
On March 3, 2014, 11:09 p.m., Vinod Kone wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18730/
> -----------------------------------------------------------
>
> (Updated March 3, 2014, 11:09 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
>
>