= Even finer grained permissions

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

----
See [http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/3160 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@oss.schwarz.eu, 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)