Edgewall Software
Modify

Opened 12 years ago

Last modified 4 years ago

#5246 new enhancement

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

Reported by: christian.seiler@… Owned by:
Priority: normal Milestone: next-major-releases
Component: version control/browser Version: 0.10-stable
Severity: normal Keywords: patch svnauthz authzsourcepolicy
Cc: Branch:
Release Notes:
API Changes:

Description

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.

Attachments (2)

authz-external-groups.patch (2.5 KB ) - added by christian.seiler@… 12 years ago.
authz-external-groups-2.patch (2.5 KB ) - added by christian.seiler@… 12 years ago.
Updated version of the patch

Download all attachments as: .zip

Change History (15)

by christian.seiler@…, 12 years ago

Attachment: authz-external-groups.patch added

comment:1 by Emmanuel Blot, 12 years ago

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.

comment:2 by christian.seiler@…, 12 years ago

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.

by christian.seiler@…, 12 years ago

Updated version of the patch

comment:3 by christian.seiler@…, 12 years ago

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

comment:4 by Christian Boos, 12 years ago

Milestone: 0.10.5
Status: newassigned

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.

comment:6 by Christian Boos, 10 years ago

Keywords: svnauthz added; authz removed

comment:7 by Remy Blank, 10 years ago

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?

in reply to:  7 ; comment:8 by Christian Boos, 10 years ago

Milestone: 0.10.50.12-multirepos

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?

in reply to:  8 comment:9 by Remy Blank, 10 years ago

Replying to cboos:

So what was the milestone?

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

comment:10 by christian.seiler@…, 10 years ago

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?

comment:11 by Christian Boos, 10 years ago

Milestone: 0.12-multireposnext-major-0.1X

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.

comment:12 by Ryan J Ollos, 6 years ago

Keywords: authzsourcepolicy added

comment:13 by Ryan J Ollos, 5 years ago

Owner: Christian Boos removed
Status: assignednew

comment:14 by figaro, 4 years ago

Keywords: patch added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned. Next status will be 'new'.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.