Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-1699

Subversion authorization with nested groups not working

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Medium Medium
    • 2.1
    • 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:

      1. Everyone has read access to the repository
      2. (unless modified below).
        [/]
      • = r
      1. Members of the subversion crowd group can
      2. 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

            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.

            David O'Flynn [Atlassian] added a comment - 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.

            uvoellger added a comment -

            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.

            uvoellger added a comment - 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.

            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.

            Renan Battaglin added a comment - 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.

            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?

              ahempel Adrian Hempel [Atlassian]
              87c5f05c9ee9 Otto Chrons
              Affected customers:
              13 This affects my team
              Watchers:
              12 Start watching this issue

                Created:
                Updated:
                Resolved: