Changes between Version 6 and Version 7 of TracDev/Proposals/EvenFinerGrainedPermissions
- Timestamp:
- Jun 24, 2015, 5:26:26 PM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/Proposals/EvenFinerGrainedPermissions
v6 v7 1 = Even finer grained permissions... =1 = Even finer grained permissions... 2 2 3 3 Starting with [milestone:0.11] and the completion of the TracDev/SecurityBranch, we enabled to have a [TracFineGrainedPermissions fine-grained permission model] at the level of individual Trac resources, making it possible to write all sorts of new permission policies. 4 4 5 == Problem ==5 == Problem 6 6 However, there are a few shortcomings with this model: 7 7 - incomplete information over the '''user''', notably identifying special relationships between the user and the resource being checked … … 26 26 Also, mixing the ''realm'' of resources into the name of actions is only a legacy of the pre-0.11 period, and besides backward compatibility there's no longer a need for that, as permissions are checked against specific resources (including `("realm", None)`-style resources representing a realm of resources in general). 27 27 28 == Solution ==28 == Solution 29 29 30 30 For extending the precision over the '''target''', we could have a very simple set of permissions (''read'', ''modify'', ''delete'', ''append'', for example) and use child resources to identify sub-elements of a resource (like fields or comments). … … 33 33 34 34 35 == Performance ==35 == Performance 36 36 37 37 … … 41 41 42 42 A few ideas: 43 - policy registration: each `IPermissionPolicy` can register "patterns" of actions, resources and users it is interested in; only fire the permissions that match es. Of course, there's a balance to find, and the pattern matching should not "cost" more than firing the rule. Also, determination of group membership should be cached when possible.44 - resource cache: some permission policies need to retrieve informations 43 - policy registration: each `IPermissionPolicy` can register "patterns" of actions, resources and users it is interested in; only fire the permissions that match. Of course, there's a balance to find, and the pattern matching should not "cost" more than firing the rule. Also, determination of group membership should be cached when possible. 44 - resource cache: some permission policies need to retrieve informationsabout the resources they're checking (e.g. [source:tags/trac-0.12/sample-plugins/permissions/vulnerability_tickets.py]). This could be avoided if the properties have already been retrieved before and we have a way to "reuse" them 45 45 46 46 … … 49 49 50 50 51 == Comments / Discussion ==51 == Comments / Discussion 52 52 53 53 One thing that annoyed me when implementing a custom policy was that the checks only get a string resource object. As I want to perform some more complex checks, I had to load the objects from the DB every time. It would be nice if the caller could pass the real db object to improve performance. (felix.schwarz@oss.schwarz.eu, 2009-09-10)
