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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
