Edgewall Software

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


Ignore:
Timestamp:
Jun 28, 2015, 11:09:27 PM (5 years ago)
Author:
figaro
Comment:

Cosmetic changes

Legend:

Unmodified
Added
Removed
Modified
  • TracDev/Proposals/EvenFinerGrainedPermissions

    v7 v8  
    1 = Even finer grained permissions...
     1= Even finer grained permissions
    22
    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.
     3Starting 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 new permission policies.
    44
    55== Problem
     6
    67However, there are a few shortcomings with this model:
    78 - incomplete information over the '''user''', notably identifying special relationships between the user and the resource being checked
     
    2425The advantage of such an approach is that we could reduce the available actions to a minimum, and at the same time give more freedom over the precision of the checks.
    2526
    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).
     27Also, 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.
    2728
    2829== Solution
     
    3233For introducing more elaborate concepts about the '''user''', we could use virtual groups. In a similar way than  the ''authenticated'' group currently represents the sets of authenticated users, we could imagine group providers attributing special membership to an user, depending on which ''resource'' is being targeted. Therefore we could imagine an ''owner'' or ''author'' virtual groups (#7438).
    3334
    34 
    3535== Performance
    36 
    3736
    3837Even today, lots of permission checks and lots of policies could have a non-negligible performance impact, not to mention the complete inefficiency of some kind of permission related queries (#4245 - who are the users having that permission?).
    3938
    40 If we're going to add even more checks like suggested here, we will also need a somewhat more efficient infrastructure for performing those checks.
     39If we're going to add even more checks like suggested here, we will also need a more efficient infrastructure for performing those checks.
    4140
    4241A few ideas:
    4342 - 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 
     43 - resource cache: some permission policies need to retrieve information about the resources they're checking, eg [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.
    4644
    4745----