[PATCH] Use permission system to store groups for authz access control

[christian.seiler@…]

We're currently using LDAP to store our users and groups. Our problem with using Subversion-style authz files for restricting access in Trac is that we'd have to define group memberships again in the authz file itself - thus we'd have to manage group memberships twice: Once in LDAP, once in the authz file (we're currently NOT using an authz file for Subversion itself for exactly this reason - we're doing it the "hard way" via Apache configuration instead). Basically, this issue is #4224 the other way 'round.

In this context, it would be great if the authz module could simply use the built-in permission system of Trac to retrieve the groups a user belongs to - and not the authz file.

I've written a patch that adds a configuration option authz_use_perm_groups that's false by default, resulting in the current behaviour. If set to true, Trac will not care about the groups section of the authz file and use the PermissionSystem to retrieve the group names instead (currently by fetching all lower-case permissions for the current user and stripping an eventual @ in front of the group name). I don't know much about the internal design of Trac so my code is probably quite ugly - but at least it works. Feel free to find a nicer solution. :-)

Please note that this patch would interfere with #4997 since Subversion itself does not implement any of this.

[Emmanuel Blot]

I'm not sure if it can help, but the ​wiki:LdapPlugin enables Trac to use permissions and permision groups defined in a LDAP directory.

[christian.seiler@…]

Yes, I'm already using ​th:wiki:LdapPlugin to store the permissions in the LDAP directory. I can use trac-admin to list and modify permissions and groups - that's not the issue.

My problem is that the svn authz file defines a separate namespace for groups that has nothing to do with the group namespace that Trac itself uses. Therefore, I'd have to define group memberships both in LDAP and in the authz file - and every time I need to add a user to a group or remove a user from a group I'd have to edit both the LDAP directory and the authz file.

My patch allows the authz access control mechanism to use the groups defined in the Trac permission system (whether they are stored traditionally in SQLite or they are stored in LDAP via ​th:wiki:LdapPlugin or elsewhere - it doesn't matter, as long as the Trac permission system sees them) instead of the groups defined in the authz file itself.

[christian.seiler@…]

Updated version of the patch

[christian.seiler@…]

I've rewritten a small part of the patch to (dramatically) increase performance - especially on systems with lot's of users.

[Christian Boos]

Looks fine.

In the future, we probably should turn the whole svn_authz into a plugin but that will probably have to wait 0.12 anyway.

[Remy Blank]

What happened here? How come this ticket was suddenly assigned to milestone:0.10.5, when there are no recent changes? Did anyone delete a comment here?

[Christian Boos]

Replying to rblank:

What happened here? How come this ticket was suddenly assigned to milestone:0.10.5, when there are no recent changes? Did anyone delete a comment here?

Yep, my fault, there was a spam "Test" comment this morning and I somehow deleted the wrong entry. I found that out later and was unable to remember what I deleted…

So what was the milestone?

[Remy Blank]

Replying to cboos:

So what was the milestone?

No idea, but I'm pretty sure it wasn't 0.10.5 ;-)

[christian.seiler@…]

Hi, I'm the reporter for the enhancement request. In the email I got with the test comment, the milestone was next-major-0.1X.

By the way, what's the status of this request?

[Christian Boos]

The fine-grained permissions for the version control subsystem are now also managed via the normal, pluggable, permission system, and the SvnAuthz is now a IPermissionPolicy (see #7116). The problem is that the group information is somehow not properly propagated in all permission policies. See #5648, which is therefore a prerequisites for this ticket. This means that the milestone should really set to a next major version, as we should now finalize 0.12.