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 all sorts of new permission policies.

Problem

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)

This has lead to put this additional precision in the permission action itself, for example:

• user related:
  • TICKET_IS_OWNER in #7438
• target related:
  • TICKET_EDIT_COMMENT in #454
  • TICKET_EDIT_DESCRIPTION in #8548

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).

Solution

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 an user, depending on which resource is being targeted. Therefore we could imagine an owner or author virtual groups (#7438).

Performance

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 somewhat more efficient infrastructure for performing those checks.

A few ideas:

• 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.
• resource cache: some permission policies need to retrieve informations about the resources they're checking (e.g. 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

---

See ​Permission model proposal

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)