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.
> 
>