launchpad-dev team mailing list archive

[Henning Eggers <henning.eggers@xxxxxxxxxxxxx>]

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.

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

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

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

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

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

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

 * Make model objects be their own authorization adapter. Why should
   it be too much to ask of an object, if a user may edit or admin it?
   The implementation can be in the class itself but may just as well
   be provided by a mix-in.

 * Provide helpful system-wide mix-ins that implement common security
   policies, e.g. for owners, admins, etc.

 * Design these mix-ins in a layered way, so that permissions can simply
   be added up and automatically include permissions from more
   restrictive policies.

 * Provide a gradual transition path. If an object does not provide its
   own authorization information, look in the old security.py for it.

 * Delete security.py! ;-)


Please comment or propose other solutions or make suggestions on how to
implement some of the ideas here.

Implementing this will take some time and should happen gradually, as
indicated. As a first step I filed this bug:
https://bugs.edge.launchpad.net/launchpad-foundations/+bug/517153

But we need more bugs to make up the plan to improve this system.

Cheers,
Henning