•  
      request #4112 Python Traceback LDAP/Active Directory connection problem while displaying SVN tree
    Infos
    #4112
    Raphaël Enrici (root42)
    2015-12-15 15:16
    2013-06-26 17:28
    2784
    Details
    Python Traceback LDAP/Active Directory connection problem while displaying SVN tree
    Dear all,

    We are using Tuleap connected to an Active Directory.
    When clicking "Afficher l'arbre SVN" we get this python traceback :

    <--- snip --->
    Traceback (most recent call last):
    File "/usr/share/viewvc/lib/viewvc.py", line 3814, in main
    request.run_viewvc()
    File "/usr/share/viewvc/lib/viewvc.py", line 318, in run_viewvc
    if not svnaccess.check_read_access(user.user_getname(), self.rootpath, self.where):
    File "/usr/share/codendi/src/www/../utils/svn/svnaccess.py", line 130, in check_read_access
    username = get_name_for_svn_access(svnrepo, username)
    File "/usr/share/codendi/src/www/../utils/svn/svnaccess.py", line 119, in get_name_for_svn_access
    return codendildap.get_login_from_username(username)
    File "/usr/share/codendi/src/www/../utils/svn/codendildap.py", line 60, in get_login_from_username
    return get_login_from_eduid(row['ldap_id'])
    File "/usr/share/codendi/src/www/../utils/svn/codendildap.py", line 43, in get_login_from_eduid
    l = ldap_connect()
    File "/usr/share/codendi/src/www/../utils/svn/codendildap.py", line 33, in ldap_connect
    l = ldap.initialize(server)
    File "/usr/lib64/python2.4/site-packages/ldap/functions.py", line 85, in initialize
    return LDAPObject(uri,trace_level,trace_file,trace_stack_limit)
    File "/usr/lib64/python2.4/site-packages/ldap/ldapobject.py", line 67, in __init__
    self._l = ldap.functions._ldap_function_call(_ldap.initialize,uri)
    File "/usr/lib64/python2.4/site-packages/ldap/functions.py", line 57, in _ldap_function_call
    result = func(*args,**kwargs)
    LDAPError: (13, 'Permission denied')
    <--- snip --->

    Replacing ldap.initialize by ldap.open on line 33 in /usr/share/codendi/src/utils/svn/codendildap.py fixes the problem which seems to be normal as $sys_ldap_server contains a simple hostname and not an URI.


    Patch follows:
    --- codendildap.py.orig 2013-06-26 17:15:03.000000000 +0200
    +++ codendildap.py 2013-06-26 17:25:44.000000000 +0200
    @@ -30,7 +30,7 @@
    def ldap_connect():
    for server in include.sys_ldap_server.split(','):
    try:
    - l = ldap.initialize(server)
    + l = ldap.open(server)
    if hasattr(include, 'sys_ldap_bind_dn'):
    l.simple_bind_s(include.sys_ldap_bind_dn, include.sys_ldap_bind_passwd)
    else:

    Thanks and best regards,
    Raphaël
    P.S. Packages versions:
    tuleap-6.1-1
    python-ldap-2.2.0-2.1
    OS: CentOS 5.9
    SCM/Subversion
    Empty
    CentOS 5 + php51
    • [ ] enhancement
    • [ ] internal improvement
    Empty
    Stage
    Empty
    Closed
    2015-12-15
    Attachments
    Empty
    References

    Follow-ups

    User avatar
    Given that the patch is merged, I close this issue.

    • Status changed from Verified to Closed
    • Reported in version cleared values: 6.1
    • Close date set to 2015-12-15
    User avatar
    Hi Raphaël,

    Thanks for the patch!
    But as you already noticed, we cannot simply apply it as it would break existing installation that already set an URI

    I'm not sure if the best way to handle it is to:
    - force admin to configure Tuleap/Ldap using a URI instead of just throwing a server
    - or, as you suggested, detect if we are about to open a connexion using a URI or a server on the fly

    Nice catch for nop vs. pass, you are right, I just pushed a commit for review for that: gerrit #573

    • Status changed from New to Verified
    User avatar
    Thinking a bit more about it, we should indeed sanitize the "server" variable content and check if it begins with ldap[s]:// or not and eventually magically add it on the fly.

    I'll try to make a patch if time permits it.

    BTW, on line 40, shouldn't the nop be replaced by pass?

    39 except ldap.SERVER_DOWN:
    40 nop


    Thanks