apiserver authorizers

[William Reade]

The case I spotted yesterday was here:
http://reviews.vapour.ws/r/3243/diff/1/?file=167369#file167369line41

and in general:

  * seeing `_ common.Authorizer` in a parameter list is a sign you're DIW.
  * failing to check some auth property when creating the facade is a sign
you're DIW.
  * failing to pass the auth on to the facade type itself *might* be OK,
but should be viewed with some suspicion -- for example:
      * an environ provisioner may have wide-ranging powers, but that's no
reason to let it see or modify container machines that are not its direct
responsibility
      * right now, many user-facing facades don't need further
authorization once they know it's an authenticated client, but that won't
last forever

helpful?

Cheers
William

On Wed, Dec 2, 2015 at 12:26 PM, roger peppe <roger.peppe at canonical.com>
wrote:

> Could you link to the offending change(s) please, so we
> can see what doing it wrong looks like?
>
> On 2 December 2015 at 09:28, William Reade <william.reade at canonical.com>
> wrote:
> > I just noticed that the unitassigner facade-constructor drops the
> authorizer
> > on the floor; and I caught a similar case in a review yesterday (that had
> > already been LGTMed by someone else).
> >
> > Doing that means that *any* api connection can use the thus-unprotected
> > facade -- clients, agents, and malicious code running in a compromised
> > machine and using the agent credentials. I don't think we have any APIs
> > where this is actually a good idea; the best I could say about any such
> case
> > is that it's not *actively* harmful *right now*. But big exploits are
> made
> > of little holes, let's make an effort not to open them in the first
> place.
> >
> > Moonstone, please fix the unitassigner facade ASAP; everyone else, be
> told,
> > and keep an extra eye out for this issue in reviews :).
> >
> > Cheers
> > William
> >
> > --
> > Juju-dev mailing list
> > Juju-dev at lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20151202/4728a3f4/attachment.html>