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 protected]> 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 protected], 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 Registry
Administrators, which is subscribed to OpenStack.
_______________________________________________
Mailing list: https://launchpad.net/~registry
Post to : [email protected]
Unsubscribe : https://launchpad.net/~registry
More help : https://help.launchpad.net/ListHelp
