Sure,
it looks like this, not very imaginative. There is currently no
authorization on the agents.
{
"permissive": false,
[...] // Here is the previous ACL with actions "run_tasks" and
"register_frameworks"
"get_endpoints": [
{
"principals": {"type": "ANY"},
"paths": {"type": "ANY"}
}
],
"view_frameworks": [
{
"principals": {"type": "ANY"},
"users": {"type": "ANY"}
}
],
"view_tasks": [
{
"principals": {"type": "ANY"},
"users": {"type": "ANY"}
}
],
"view_executors": [
{
"principals": {"type": "ANY"},
"users": {"type": "ANY"}
}
],
"access_sandboxes": [
{
"principals": {"type": "ANY"},
"users": {"type": "ANY"}
}
],
"access_mesos_logs": [
{
"principals": {"type": "ANY"},
"logs": {"type": "ANY"}
}
]
}
On 10.06.2016 00:17, Greg Mann wrote:
> Benno,
> Would you mind providing more information on the ACL definitions that you
> used to gain full access to the web UI? I'm working on some more
> documentation for this. Also, did you have authorization enabled on the
> agents as well?
>
> Cheers,
> Greg
>
> On Wed, Jun 8, 2016 at 7:43 AM, Neil Conway <neil.con...@gmail.com> wrote:
>
>> On Wed, Jun 8, 2016 at 4:27 PM, Alexander Rojas <alexan...@mesosphere.io>
>> wrote:
>>> I think we should also think more thoroughly about the expected behaviour
>>> when we introduce new authorizable actions (and we most certainly will).
>>> Since things may break particularly if users set the `permissive` ACL
>> field
>>> to false.
>>>
>>> Perhaps initially, if no ACL is given for the new action we print a
>> warning
>>> message and behave as if the field had an ACL such as
>>>
>>> ```
>>> {
>>> "principals": {"type": "ANY"}
>>> "action":{"type": "ANY"}
>>> }
>>> ```
>>
>> An ACL configuration that omits any rules for a particular action is
>> not an invalid way to configure the system. e.g., suppose we added the
>> "/teardown" endpoint in Mesos 1.1, along with the
>> "teardown_frameworks" ACL. A perfectly reasonable way to configure the
>> behavior "no one should be allowed to use the /teardown endpoint" is
>> an ACL configuration that has "permissive: false" and doesn't
>> otherwise mention "teardown_frameworks".
>>
>> The situation here is a little unusual, because we're introducing ACLs
>> for behavior that was previously not covered by the authorization
>> system, rather than new functionality. But overall, I think the
>> situation can be addressed by documenting the new behavior
>> *prominently* in the release notes / upgrade docs -- anyone upgrading
>> to a non-patch release should be reading that document anyway, and the
>> required changes will usually be straightforward.
>>
>> Neil
>>
>
