WSGI has an environ dictionary that is for storing context about the
request; would it make sense to replace APIRequestContext entirely, just
passing the environ dict around?  Pro: reuses WSGI concept.  Con: passing
around a dictionary that has more info in it than strictly needed; risks
coupling the code to WSGI more tightly.

- Michael

On Tue, Sep 21, 2010 at 2:18 PM, vishvananda <email address hidden> 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.
>
>
>


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.