Edgewall Software

Changes between Version 6 and Version 7 of TracDev/Proposals/EvenFinerGrainedPermissions


Ignore:
Timestamp:
Jun 24, 2015, 5:26:26 PM (5 years ago)
Author:
Ryan J Ollos
Comment:

Grammar fixes.

Legend:

Unmodified
Added
Removed
Modified
  • TracDev/Proposals/EvenFinerGrainedPermissions

    v6 v7  
    1 = Even finer grained permissions... =
     1= Even finer grained permissions...
    22
    33Starting 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.
    44
    5 == Problem ==
     5== Problem
    66However, there are a few shortcomings with this model:
    77 - incomplete information over the '''user''', notably identifying special relationships between the user and the resource being checked
     
    2626Also, 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).
    2727
    28 == Solution ==
     28== Solution
    2929
    3030For 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).
     
    3333
    3434
    35 == Performance ==
     35== Performance
    3636
    3737
     
    4141
    4242A few ideas:
    43  - policy registration: each `IPermissionPolicy` can register "patterns" of actions, resources and users it is interested in; only fire the permissions that matches. 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 about 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
     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
    4545
    4646
     
    4949
    5050
    51 == Comments / Discussion ==
     51== Comments / Discussion
    5252
    5353One 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)