launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

On Thu, Feb 04, 2010 at 06:37:29PM +0100, Henning Eggers wrote:
> Hi all,
> in some of my recent work I was confronted with parts of the
> Launchpad/Zope security system, namely the IAuthorization adapters in
> lib/canoncial/launchpad/security.py. I think this file and the concept
> behind it could use some serious improving to be easier to handle and
> less error-prone.

Hi Henning,

thanks for taking time to think about how the security system could be
improved. I have some reservations, though. I think we need a better
plan, before doing anything major, though. I think there are several
problems with the current system, but I think we can do much better.
However, I think it's quite low priority at the moment; we have more
pressing issues to deal with. I'll add it to my todo, though, and if
Danilo agrees that this is something that you could spend time on,
you're of course very welcome to help figuring out how the new system
should work, and to implement it.


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

This is something that I think is OK to do now. It's a simple thing to
do, and it moves code away from canonical.launchpad. +1 on this, even
though we might choose another path in the future.



>  * Security questions (canEdit, canAdmin) sometimes need to be asked in
>    model code, too, because parameter values cannot be restricted
>    through the Zope security system. So to check if a certain user is
>    allowed to pass a certain parameter value to a method, checks similar
>    to those in security.py need to be performed. This causes code
>    duplication and is difficult to keep in sync.

The current solution is to have this code in model code, and have the
security adapter ask the model. No code duplication really.


>  * Permission implementers have to watch to always implement all access
>    levels. For example, when checking which users have "launchpad.Edit"
>    on an object, the permissions for "launchpad.Admin" have to be
>    included, too. This has to happen manually by either calling
>    inherited methods or by (again) duplicating code.

I agree that this is a small issue.


> = Needed improvements =
> 
>  * Split permission checking up into chunks for each Launchpad
>    application. At the same time, general policies need to be available
>    to all parts.
> 
>  * Have a canonical way to use the same checks in model code as in view
>    code.

We already have this. Have the check in model code, and have the
security adapter ask the model.


>  * Make the system automatically layered, so that less restrictive
>    access levels automatically include more restrictive levels.
>    Exceptions need to be possible, of course, to model special
>    situations.

This is a reasonable requirement. I wouldn't talk so much about access
levels, though. It's more people in a context. Admins should be allowed
pretty much everything. Project owners should be allows pretty much
anything that is related to their project (it gets a big more
complicated when dealing with private objects). Bug supervisors should
be allowed anything related to bugs within a project. So you end up with
a structure that depends on the object, and the type of the attribute.
It might be solved by adding a bunch of new permissions, but I'd rather
now. I suspect that the right solution is to get rid of permissions
(like launchpad.Edit) and use something else instead. I don't think that
trying to band-aid the current system give us much gain.


> = Possible solutions =
> I don't have all the answers but these are some of my ideas.

Some of these are ideas are nice, but let's start with thinking about
what we need the new security system to do. For example, one important
property is that it should tell us why something isn't allowed, so that
we can inform the user why he can't do certain things.

A good start would be to create a wiki page, where we collect all the
requirements.


-- 
Björn Tillenius | https://launchpad.net/~bjornt