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.

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)
• 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:
  • TICKET_EDIT_COMMENT in #454
  • TICKET_EDIT_DESCRIPTION in #8548
  • TICKET_EDIT_MILESTONE in #8778

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

---

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)