= 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 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 [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)