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
>
