Maybe we can just supply a default acl template file specifying these
defaults acls. Then users will have more guidance when starting to use acls.
I will create a sample patch to clarify how I envision such kind of
template :-).
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"}
> }
> ```
>
> which effectively set a permissive rule for that action. The advantage is
> that
> it will give time for users to update the ACLs, the disadvantage is that we
> would be introducing incorrect semantics (if temporarily).
>
> The other idea would be to detect `permissive=false` and no ACLs given
> for the new action and print a warning message about possible breaks
> because of a change in the system, but no change in behaviour.
>
> Any other ideas?
>
> On Wed, Jun 8, 2016 at 1:30 AM, Greg Mann <g...@mesosphere.io> wrote:
>
> > Hi Evers,
> > Thanks for testing this out! We should have called out this change more
> > explicitly in the changelog; I've posted a patch here
> > <https://reviews.apache.org/r/48380/> to do that.
> >
> > Adding documentation with guidance on how to set ACLs to accomplish
> > particular tasks (i.e., full use of the web UI) would be beneficial as
> > well, but seems out of scope for the release notes. I've created a JIRA
> to
> > update the authorization documentation here
> > <https://issues.apache.org/jira/browse/MESOS-5564>.
> >
> > Cheers,
> > Greg
> >
> >
> > On Mon, Jun 6, 2016 at 2:28 AM, Evers Benno <ben...@yandex-team.ru>
> wrote:
> >
> > > Hi,
> > >
> > > thanks for the pointer. For people having the same problem, it seems
> > > that you have to actually provide six new ACL rules to restore the
> > > previous behaviour:
> > >
> > > get_endpoints, view_frameworks, view_tasks, view_executors,
> > > access_sandboxes, and access_mesos_logs.
> > >
> > > On 03.06.2016 21:59, Michael Park wrote:
> > > > Hello, I'm not exactly sure about whether the behavior is undesired
> or
> > > not.
> > > >
> > > > But I think the ACL that you're missing is `GetEndpoint`:
> > > >
> > >
> >
> https://github.com/apache/mesos/blob/master/include/mesos/authorizer/acls.proto#L183-L190
> > > >
> > > > Hope that helps,
> > > >
> > > > MPark
> > > >
> > > > On 3 June 2016 at 12:36, Evers Benno <ben...@yandex-team.ru> wrote:
> > > >
> > > >>
> > > >> I just tried building and running the 1.0.0-rc1, and it seems that
> the
> > > >> web UI is broken due to /metrics/snapshot returning a 403. (There's
> a
> > > >> popup continously displaying "Failed to connect to
> > > >> mesos-master.example.org:5050!"
> > > >>
> > > >> I'm running mesos-master with options `--no-authenticate_http
> > > >> --acls={"permissive": "false", [...]}`, so I'm not completely sure
> if
> > > >> this behaviour is as desired or not. (although its certainly
> > unexpected)
> > > >>
> > > >> Regardless, I looked around for a while, but I couldn't figure out
> > what
> > > >> to add to the ACL to restore unauthorized viewing access for
> everyone?
> > > >>
> > > >> Best regards,
> > > >> Benno
> > > >>
> > > >
> > >
> >
>
