launchpad-dev team mailing list archive

[Henning Eggers <henning.eggers@xxxxxxxxxxxxx>]

Am 05.02.2010 05:42, Stuart Bishop schrieb:
> On Fri, Feb 5, 2010 at 12:37 AM, Henning Eggers
> <henning.eggers@xxxxxxxxxxxxx> wrote:
> 
>> = Current situation =
>>
>>  * security.py is a big blob of mostly unrelated classes from all parts
>>   of Launchpad. Only relation is the same base class
>>   AuthorizationBase. This makes the file very big.
> 
> It also is supposed to make it easy to audit, as our security
> declarations are in one place rather than scattered around the code
> base. This was one of the original goals. I have no idea if we have met
> that goal.

I don't think 150+ classes on 2200+ lines of code are easy to audit. I
admit, putting the declarations closer to the code does scatter them a
bit but it should not be too hard to come up with an audition tool that
lists all of them.


> I don't know if we have special situations any more. The perverse use
> cases that required 'super special' permissions (you can do stuff but an
> admin can't) are gone I think.

That would be great! Looking at the code in security.py, though, I see
the classes checking all kinds of conditions. Maybe some of these checks
are over-paranoid and could be simplified. It would be great to simple
hierarchical permissions:

1. Admins
2. Application Experts
3. Owners/Maintainers
4. Drivers
5. Uploaders
6. Team members
7. Logged-in users
8. Everybody

But I don't see that atm. For example, in Rosetta the Ubuntu Translation
Coordinators get admin permissions on upload entries targeted to Ubuntu,
so we need to check team membership and a property on the object being
protected.

That said, I would prefer the approach of having more than the current
three or four permissions (like 8 or more as above) and putting them in
a strict hierarchical order. I just think that this approach would need
a lot of re-thinking of how we work with permissions.

> 
>> Please comment or propose other solutions or make suggestions on how to
>> implement some of the ideas here.
> 
> Or permissions now might be sane enough to generate them from a config
> file rather than code. This would certainly be useful for the UI hints
> people have been asking for saying 'you can't do this, but these people
> can'.

I don't think they are sane enough atm but with an approach like above
that could be achieved.

There would still the question to be solved of how to restrict values of
method parameters.

Henning