|Version 11 (modified by 4 years ago) ( diff ),|
Even finer grained permissions
Starting with 0.11 and the completion of the TracDev/SecurityBranch, we enabled to have a fine-grained permission model at the level of individual Trac resources, making it possible to write new permission policies.
However, there are a few shortcomings with this model:
- incomplete information over the user, notably identifying special relationships between the user and the resource being checked
- lack of precision over the target of the check (#8653)
- inability to infer the permission that needs to be checked (#13022)
This has lead to proposed or actual changes that add precision in the permission action itself, for example:
- user related:
- TICKET_IS_OWNER in #7438
- target related:
IPermissionPolicy plugins have the same tendency.
I think that instead of pursuing in this direction, we should plan to re-balance each of the three aspects of a permission check:
- the action should correspond to the verb (which action is performed)
- the user should correspond to the subject (who performs the action)
- the resource should correspond to the noun (what is concerned by the action)
The 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.
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.
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).
For 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 a user, depending on which resource is being targeted. Therefore we could imagine an owner or author virtual groups (#7438).
Even 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?).
If we're going to add even more checks like suggested here, we will also need a more efficient infrastructure for performing those checks.
A few ideas:
- policy registration: each
IPermissionPolicycan 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.
- resource cache: some permission policies need to retrieve information about the resources they're checking, eg tags/trac-1.2/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.
Comments / Discussion
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@…, 2009-09-10)
… no comment, you were obviously not on Trac-dev at the time doing such things was considered absurd / bad taste / whatever by former Trac developers. I'd glad to get feedback from Remy and Simon about this, though (cboos)