[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Can i read/write(based on LDAP group) to SVN without using AuthzSVNAccessFile directive

From: Kedar Sirshikar (ksirshik) <ksirshik_at_cisco.com>
Date: Tue, 5 Sep 2017 19:25:53 +0000

Hi Brane,
I just found out that it is still referring to ‘/var/www/svn/users-access-file’ even after removing it from subversion.conf. I also deleted ‘users-access-file’ file from ‘/var/www/svn’
I even tried commenting below line from subversion.conf but still same error.
#LoadModule authz_svn_module modules/mod_authz_svn.so

In every case, I am still getting 403 error in logs:

[Tue Sep 05 08:11:33 2017] [error] [client 172.16.2.14] (2)No such file or directory: Failed to load the AuthzSVNAccessFile: Can't open file '/ var/www/svn/users-access-file': No such file or directory

I am not able to understand why it is still referring to earlier configured ‘AuthzSVNAccessFile /var/www/svn/users-access-file’ directive.

Regards,
Kedar.

From: "Kedar Sirshikar (ksirshik)" <ksirshik_at_cisco.com>
Date: Sunday, September 3, 2017 at 12:36 PM
To: Branko Čibej <brane_at_apache.org>, "users_at_subversion.apache.org" <users_at_subversion.apache.org>
Subject: Re: Can i read/write(based on LDAP group) to SVN without using AuthzSVNAccessFile directive

Thank you, Brane, for your reply.

I updated subversion.conf to include group’s attribute memberUid

    AuthLDAPURL ldaps://ldap_l.cisco.com:10648/dc=sprint,dc=com?hasSubordinates,objectClass?sub?uid



    AuthLDAPBindDN uid=admin,ou=system

    AuthLDAPBindPassword secret



    AuthzLDAPAuthoritative on

    AuthLDAPGroupAttributeIsDN off

    #AuthLDAPGroupAttribute cn

    AuthLDAPGroupAttribute memberUid

        #<RequireAll>

            Require valid-user

            <Limit HEAD GET OPTIONS PROPFIND REPORT>

                #<RequireAny>

                    # Read access

                    Require ldap-group cn=User,ou=groups,dc=sprint,dc=com

                #</RequireAny>

            </Limit>

            <LimitExcept HEAD GET OPTIONS PROPFIND REPORT>

                #<RequireAny>

                    # Write access

                    Require ldap-group cn=Roles,ou=groups,dc=sprint,dc=com

                    Require ldap-attribute gidNumber=491

                    #Require ldap-group cn=Admin,ou=groups,dc=sprint,dc=com

                #</RequireAny>

            </LimitExcept>

        #</RequireAll>

I have also updated screen shots for sssd_pb and Roles group. I feel there is something wrong in this ldif because of which it is still not working.

Output of ldapsearch is

KSIRSHIK-M-33TW:~ ksirshik$ ldapsearch -H ldaps://ldap_l.cisco.com:10648 -x -D "uid=admin,ou=system" -W -b "dc=sprint,dc=com" -s sub -a always -z 1000 "uid=sssd_pb"

Enter LDAP Password:

# extended LDIF

#

# LDAPv3

# base <dc=sprint,dc=com> with scope subtree

# filter: uid=sssd_pb

# requesting: ALL

#



# sssd_pb, Admin, groups, sprint.com

dn: uid=sssd_pb,cn=Admin,ou=groups,dc=sprint,dc=com

sn: sn_sssd_pb

cn: cn_sssd_pb

objectClass: posixAccount

objectClass: top

objectClass: inetOrgPerson

objectClass: person

objectClass: organizationalPerson

homeDirectory: /home/qns-svn

gidNumber: 491

uidNumber: 491

userPassword:: e1NTSEF9dGFPUmpYdTZ4TUxUemdmTjJVVlE3TkJiRVQwYkVqZWxTQ2V2T3c9PQ=

 =

uid: sssd_pb



# sssd_pb, users, sprint.com

dn: uid=sssd_pb,ou=users,dc=sprint,dc=com

sn: sn_sssd_pb

cn: cn=Admin,ou=groups,dc=sprint,dc=com

objectClass: posixAccount

objectClass: top

objectClass: inetOrgPerson

objectClass: person

objectClass: organizationalPerson

homeDirectory: /home/qns-svn

gidNumber: 491

uidNumber: 491

userPassword:: e1NTSEF9Qi94UDJVK3dtbWFDQW5hRVR5ZW1uL2RnenFudnBMdlNoaUxkOFE9PQ=

 =

uid: sssd_pb



# search result

search: 2

result: 0 Success



# numResponses: 3

# numEntries: 2

KSIRSHIK-M-33TW:~ ksirshik$



Regards,
Kedar.

From: Branko Čibej <brane_at_apache.org>
Organization: The Apache Software Foundation
Date: Saturday, September 2, 2017 at 5:07 AM
To: "Kedar Sirshikar (ksirshik)" <ksirshik_at_cisco.com>, "users_at_subversion.apache.org" <users_at_subversion.apache.org>
Subject: Re: Can i read/write(based on LDAP group) to SVN without using AuthzSVNAccessFile directive

On 02.09.2017 03:50, Kedar Sirshikar (ksirshik) wrote:
Hi Brane,
I tried to follow your suggestions. Please refer attached latest version of ‘subversion.conf’

1. I updated my subversion.conf to include ‘AuthLDAPGroupAttribute’ attribute. Its value is set to cn as cn attribute has the group name (to which user is assigned)

AuthLDAPGroupAttribute is the name of the group's member list attribute, not the user's primary group attribute.



Is there any way I can check for logs? If I get some relevant logs, I myself can dig down more.

You should have Apache server logs available. If they're not detailed enough, you can increase the log verbosity.



I came across below 2 urls which claim that it is not possible to get rid of AuthzSVNAccessFile directive and you must use a file to configure groups and users.
http://grokbase.com/t/subversion/users/1477dcf8yc/how-to-control-access-of-a-subversion-repo-subfolder-via-ad-groups/oldest#responses_tab_top
https://github.com/whitlockjc/sync-ldap-groups-to-svn-authz

Now, I am little confused about whether it is really possible (or not) to fully avoid configuring groups and user names in a separate file.

That depends on what you want to do. If you only want to control read-only vs. read-write access to the whole repository, you can do that in the Apache config, as I showed you. If you want more fine-grained access control, that's what the Subversion authz file is for. If you want to do that per-user, then you will have to define users (and/or groups) in that file. And yes, there are tools out there for automatically generating user and group lists for the Subversion authz file from LDAP.

-- Brane


Received on 2017-09-05 21:26:13 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.