The term "proper object" isn't very pythonic, silly Devin man. Nothin wrong
with a dict - it's a "proper object", too.

On Tue, Sep 21, 2010 at 9:06 PM, Devin Carlen <email address hidden>wrote:

> I like the practice of providing context all the way down the call
> stack.  However I think first class citizens should not be dictionaries.
> We can accomplish the same thing with a proper object that implements
> todict()/fromdict().
>
> Devin
>
>
> On Sep 21, 2010, at 11:18 AM, vishvananda wrote:
>
> > My thoughts on data authentication:
> > First we turn context into a dictionary so it is easy to pass around
> everywhere.   The dictionary contains the following important data:
> > {'request_id': <random req string>,
> > 'user_id': ...,
> > 'project_id': ...,
> > 'superuser': <boolean, for bypassing project checking>
> > 'deleted' <tristate yes, no, all>}
> >
> > superuser is set during authentication of the request, simply to avoid
> > roundtrips to the auth layer.
> >
> > My preference for a dictionary is simply that it is easy to pass through
> > rabbit.
> >
> > then inside the data layer, we have a simple check:
> > if context['superuser']:
> > # don't limit the sql
> > elif context['project_id']:
> > # add project_id = context
> > else:
> >  raise
> > switch on deleted to add deleted=0, deleted=1 or ignore
> >
> > The user_id and request_id aren't used in the datalayer but are in
> > context to help with logging.
> >
> > On Sep 21, 2010, at 8:52 AM, Michael Gundlach wrote:
> >
> >> On Tue, Sep 21, 2010 at 8:16 AM, Soren Hansen <email address hidden> wrote:
> >>
> >>> Now that I think about it, I'm not sure how they're supposed to work?
> >>> They're applied before the object(s) being accessed are even known, so
> >>> it only really checks if context.user has the given role on
> >>> context.project, right? So any checks further down should check whether
> >>> the object being accessed belongs to context.project. Is that accurate?
> >>>
> >>
> >> Yep, that's accurate.  The conversion from Tornado to eventlet (as of
> yet
> >> unmerged to trunk) moves all that into an "Authorization" middleware.
>  It
> >> might help clarify the code if that were renamed to
> "MethodAuthentication"
> >> and we do data authentication somewhere else.
> >>
> >>
> >> Confidentiality Notice: This e-mail message (including any attached or
> >> embedded documents) is intended for the exclusive and confidential use
> of the
> >> individual or entity to which this message is addressed, and unless
> otherwise
> >> expressly indicated, is confidential and privileged information of
> Rackspace.
> >> Any dissemination, distribution or copying of the enclosed material is
> prohibited.
> >> If you receive this transmission in error, please notify us immediately
> by e-mail
> >> at <email address hidden>, and delete the original message.
> >> Your cooperation is appreciated.
> >>
> >> --
> >> authorization not checked in ec2 api
> >> https://bugs.launchpad.net/bugs/644092
> >> You received this bug notification because you are a member of Nova
> >> Bugs, which is subscribed to OpenStack Compute (nova).
> >>
> >> Status in OpenStack Compute (Nova): New
> >>
> >> Bug description:
> >> Users can see things they shouldn't be able to.
> >>
> >> STEPS:
> >>
> >> 0) create two users a & b, NOT in the same project
> >>
> >> 1) start an instance as user a
> >>
> >> 2) get_console_output on user a's instance as user b
> >>
> >> EXPECTED:
> >>
> >> the user should not get the output (user b should not be able to get
> console output for instances they don't own)
> >>
> >> ACTUAL:
> >>
> >> console output from instance is returned successfully
> >>
> >> DETAILS:
> >>
> >> for instance, get_console_output in cloud.py:
> >>
> >>  def get_console_output(self, context, instance_id, **kwargs):
> >>      instance_ref = db.instance_get_by_str(context, instance_id[0])
> >>      return rpc.call('%s.%s' % (FLAGS.compute_topic,
> >>                                 instance_ref['host']),
> >>                      {"method": "get_console_output",
> >>                       "args": {"context": None,
> >>                                "instance_id": instance_ref['id']}})
> >>
> >> sends a context (which has the user/project) into the
> instance_get_by_str function, but context is not used in the db layer to
> determine if the user has access to the instance.
> >>
> >> Similarly for all other data store objects.
> >>
> >> PROPOSAL:
> >>
> >> My thought is that the datalayer should only return objects that the
> user is authorized to see.  If we check at the API layer instead of the data
> access layer, we have the possibility of inconsistent rules for the same
> data types as the API evolves.
> >>
> >>
> >
> > --
> > authorization not checked in ec2 api
> > https://bugs.launchpad.net/bugs/644092
> > You received this bug notification because you are a member of Nova
> > Bugs, which is subscribed to OpenStack Compute (nova).
> >
> > Status in OpenStack Compute (Nova): New
> >
> > Bug description:
> > Users can see things they shouldn't be able to.
> >
> > STEPS:
> >
> > 0) create two users a & b, NOT in the same project
> >
> > 1) start an instance as user a
> >
> > 2) get_console_output on user a's instance as user b
> >
> > EXPECTED:
> >
> >  the user should not get the output (user b should not be able to get
> console output for instances they don't own)
> >
> > ACTUAL:
> >
> >  console output from instance is returned successfully
> >
> > DETAILS:
> >
> > for instance, get_console_output in cloud.py:
> >
> >   def get_console_output(self, context, instance_id, **kwargs):
> >       instance_ref = db.instance_get_by_str(context, instance_id[0])
> >       return rpc.call('%s.%s' % (FLAGS.compute_topic,
> >                                  instance_ref['host']),
> >                       {"method": "get_console_output",
> >                        "args": {"context": None,
> >                                 "instance_id": instance_ref['id']}})
> >
> > sends a context (which has the user/project) into the instance_get_by_str
> function, but context is not used in the db layer to determine if the user
> has access to the instance.
> >
> > Similarly for all other data store objects.
> >
> > PROPOSAL:
> >
> > My thought is that the datalayer should only return objects that the user
> is authorized to see.  If we check at the API layer instead of the data
> access layer, we have the possibility of inconsistent rules for the same
> data types as the API evolves.
> >
> >
>
> --
> authorization not checked in ec2 api
> https://bugs.launchpad.net/bugs/644092
> You received this bug notification because you are a member of Nova
> Bugs, which is subscribed to OpenStack Compute (nova).
>
> Status in OpenStack Compute (Nova): New
>
> Bug description:
> Users can see things they shouldn't be able to.
>
> STEPS:
>
> 0) create two users a & b, NOT in the same project
>
> 1) start an instance as user a
>
> 2) get_console_output on user a's instance as user b
>
> EXPECTED:
>
>   the user should not get the output (user b should not be able to get
> console output for instances they don't own)
>
> ACTUAL:
>
>   console output from instance is returned successfully
>
> DETAILS:
>
> for instance, get_console_output in cloud.py:
>
>    def get_console_output(self, context, instance_id, **kwargs):
>        instance_ref = db.instance_get_by_str(context, instance_id[0])
>        return rpc.call('%s.%s' % (FLAGS.compute_topic,
>                                   instance_ref['host']),
>                        {"method": "get_console_output",
>                         "args": {"context": None,
>                                  "instance_id": instance_ref['id']}})
>
> sends a context (which has the user/project) into the instance_get_by_str
> function, but context is not used in the db layer to determine if the user
> has access to the instance.
>
> Similarly for all other data store objects.
>
> PROPOSAL:
>
> My thought is that the datalayer should only return objects that the user
> is authorized to see.  If we check at the API layer instead of the data
> access layer, we have the possibility of inconsistent rules for the same
> data types as the API evolves.
>
>
>