-
Bug
-
Resolution: Fixed
-
Medium
-
2.0.1
-
None
-
Java Version:
1.6.0_16
Java Vendor:
Sun Microsystems Inc.
JVM Version:
14.2-b01
JVM Vendor:
Sun Microsystems Inc.
JVM Runtime:
Java HotSpot(TM) 64-Bit Server VM
Authorization in Subversion doesn't work if users are in nested groups. It works if they are directly in the "subversion" group that is mapped to the subversion application.
We are using the dav_svn.authz file to configure access like this:
- Everyone has read access to the repository
- (unless modified below).
[/]
- = r
- Members of the subversion crowd group can
- read and write to the hole repository project
[/]
@subversion = rw
If users belong directly to group "subversion", they get access, but if they are in a nested group inside "subversion" group, authorization fails.
[CWD-1699] Subversion authorization with nested groups not working
This is very painful. Providing nested groups but supporting it correctly in neither SVN connector nor Confluence (see http://jira.atlassian.com/browse/CONF-19431) makes this feature useless.
Eric Dalquist
added a comment - This is also a rather painful issue for us as well. We have 11 groups that have access to various SVN paths and a few paths we want everyone to have access to. Being able to have an 'all SVN committers' group without having to maintain users in multiple groups would be a huge help.
Eric Dalquist
added a comment - This is also a rather painful issue for us as well. We have 11 groups that have access to various SVN paths and a few paths we want everyone to have access to. Being able to have an 'all SVN committers' group without having to maintain users in multiple groups would be a huge help. The Crowd SVN Connector uses two different SOAP APIs: isGroupMember and findGroupMemberships.
Calls to isGroupMember do support nested groups and are used only when the CrowdAllowedGroups variable is defined in the SVN/Apache configurations. This would be the only way to use nested groups at the moment.
See more details about the CrowdAllowedGroups variable here.
Calls to findGroupMemberships do not support nested groups and are used every time the CrowdAuthzSVNAccessFile (fine-grained access) is set with a file containing the permissions.
So, it seems that the connector supports nested groups for the Apache configuration file only, not for CrowdAuthzSVNAccessFile.
Elijah Flesher
added a comment - I would love this to be fixed - it seems that there is a lot broken about the crowd/apache/svn authentication
Elijah Flesher
added a comment - I would love this to be fixed - it seems that there is a lot broken about the crowd/apache/svn authentication 
Kevin Ross
added a comment - This is killing me. We just did a crowd reorganization based on the long awaited feature of nested groups, and this has broken our SVN access.
Our company is growing and nested groups is important to us to maintain our sanity. This reorg was one step in that direction, to make sure that confidentiality is maintained easily through group association. Now that we have completed the reorg, we need to go back to the mess?
SVN/Apache/Crowd integration is supported correct?
Kevin Ross
added a comment - This is killing me. We just did a crowd reorganization based on the long awaited feature of nested groups, and this has broken our SVN access.
Our company is growing and nested groups is important to us to maintain our sanity. This reorg was one step in that direction, to make sure that confidentiality is maintained easily through group association. Now that we have completed the reorg, we need to go back to the mess?
SVN/Apache/Crowd integration is supported correct?
With Crowd 2.1, we'll be providing a REST API that correctly resolves nesting. We're also working on a version of the svn connector that will use this API and so do nesting properly.