launchpad-dev team mailing list archive

[Henning Eggers <henning.eggers@xxxxxxxxxxxxx>]

Am 21.12.2010 19:51, schrieb Gary Poster:
> On Dec 21, 2010, at 1:23 PM, Henning Eggers wrote:
>>
>> It would be interesting to know if this behavior is intended and deterministic.
> 
> Yes.  The first is always regarded as the most important, in this and other aspects.

Aha, good to know. Thank you.

>> The IAuthorization objects in security.py get registered as adapters from
>> "<usedfor>" to IAuthorization, named "<permission>". With the behavior I
>> identified here, it follows that the selection of the security policy depends
>> on the order in which the "implement" statement of the "Product" class lists
>> interfaces. In this case, the Adapter for IHasCustomLangugeCodes shadows the
>> adapter for IProduct because that list is sorted alphabetically AFAICT.
> 
> I'm not familiar with anything alphabetical being involved.

I was referring to the convention used in Launchpad code. AFAICT the
interfaces in the "implements" list are sorted alphabetically but some
implementation break that rule. I just did a quick survey and at least Person
and ProjectGroup have IPerson and IProjectGroup first in their lists. With
others I can't tell because the main interface comes alphabetically first
anyway (Distribution, Archive, etc.) so it may be deliberate or not.

Putting the main interface first in this list seems to conform to the "most
important" rule that you mentioned. I can only assume that it was done on
purpose to deal with security.py issues. Maybe Curtis can confirm this.

> 
>>
>> I was not aware of this. Is everybody else? Is this intended? Is this good?
> 
> I think it is good for the adapter registry: it is a simple rule that can be
> relatively easily reasoned about, as opposed to something with more
> heuristics.

Oh yeah, definitely. I am not questioning the way adapter look-up works in
Zope. ;)

> 
> In this context, I've never done a thoughtful survey of Launchpad's security
> machinery, and don't have a concrete opinion as to its usage of the adapter
> machinery.  It sounds like a "Gotcha" at best, in this context.

This is what I was questioning. Because the security machinery uses a simple
"queryAdapter" to find the right security adapter, it is important to
understand how the adapter machinery works. Putting the main interface first
in the "implements" list sees like a good convention for me to achieve
deterministic interaction with the security policy. If it already is a
convention then it is not being followed and that lead to a "gotcha" for me.

A more complete "fix" would be to have the security policy query all security
adapters for the given situation and only allow access if all adapters allow
it. I don't think that the adapter machinery can be used to do that, though. I
thought something like the following might work but a casted obj is still an
obj and the same adapter is returned every time.

    for iface in providedBy(obj):
        adapted = queryAdapter(iface(obj), ITarget, "the_name")

Should I file a bug for this (improving LP security policy) or does anybody
know of a fitting one?

Henning