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