httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 33198] - [PATCH] mod_auth_ldap authorization phase causing segfault
Date Thu, 27 Jan 2005 13:54:55 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33198>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33198





------- Additional Comments From speeves@erikin.com  2005-01-27 14:54 -------
(In reply to comment #2)
> Could you check for me whether this bug still exists in the latest trunk version
> of httpd v2.1 and apr v1.1?
> 
> LDAP development is now focused on the httpd v2.1 and apr v1.1 branches, as the
> code in httpd v2.0 needed to be largely overhauled to work correctly.
> 
The SEGFAULT does not occur in httpd v2.1 and apr v1.1, (Jan. 21, 2005 trunk),
but another issue(?) does show itself:

<snip>
debian unstable:
libldap2 2.1.30-3
libldap2-dev 2.1.30-3
httpd-2.1 trunk (Jan 21, 2005)
apr* trunk (Jan 21, 2005)

LDAP Server:
Novell eDirectory 8.7.3

1. if user authenticates with mod_auth_basic
2. doesn't belong to group in htgroup file which has authorization for accessing
files, etc.
3. mod_auth_basic declines to mod_authnz_ldap
4. at mod_authnz_ldap.c->authz_ldap_check_user_access line 543
5. if req doesn't exist (!req), then call:
5. util_ldap.c function util_ldap_cache_getuserdn with ldc->bound = 1 (this
would be the second time that the user tries to login).
 a. (?) line 1109 -- tries to connect to the ldap server with the dn built from
username sent by end-user. 
 b. (?) fails to bind
 c. line 1114 -- tries to use the cached connection to ldap server to search,
which causes:

/************ begin backtrace  ******************/

Program received signal SIGPIPE, Broken pipe.
0xb7d9b5ae in __write_nocancel () from /lib/tls/libpthread.so.0

(gdb) backtrace
#0  0xb7d9b5ae in __write_nocancel () from /lib/tls/libpthread.so.0
#1  0xb7e2606d in ber_int_sb_write () from /usr/lib/liblber.so.2
#2  0xb7e26b57 in ber_int_sb_write () from /usr/lib/liblber.so.2
#3  0xb7e25ec4 in ber_int_sb_write () from /usr/lib/liblber.so.2
#4  0xb7e22be9 in ber_flush () from /usr/lib/liblber.so.2
#5  0xb7e45117 in ldap_int_flush_request () from /usr/lib/libldap.so.2
#6  0xb7e45308 in ldap_send_server_request () from /usr/lib/libldap.so.2
#7  0xb7e4502a in ldap_send_initial_request () from /usr/lib/libldap.so.2
#8  0xb7e3662e in ldap_search_ext () from /usr/lib/libldap.so.2
#9  0xb7e3675b in ldap_search_ext_s () from /usr/lib/libldap.so.2
#10 0x080a2e75 in util_ldap_cache_getuserdn (r=0x82830e8, ldc=0x8216498, 
    url=0x8209250 "ldap://ldap.example.com:389/ou=users,o=example?uid", 
    basedn=0x8209290 "ou=users,o=example", scope=2, attrs=0x82092a0, 
    filter=0xbfffd4d0 "(&(objectclass=*)(uid=username))", binddn=0xbfffd4cc, 
    retvals=0xbfffd4c8) at util_ldap.c:1114
#11 <function called from gdb>
#12 authz_ldap_check_user_access (r=0x82830e8) at mod_authnz_ldap.c:551
#13 0x0807a229 in ap_run_auth_checker (r=0x82830e8) at request.c:76
#14 0x0807a87d in ap_process_request_internal (r=0x82830e8) at request.c:200
#15 0x080dc629 in ap_process_request (r=0x82830e8) at http_request.c:253
#16 0x080d9715 in ap_process_http_connection (c=0x826f230) at http_core.c:171
#17 0x08087644 in ap_run_process_connection (c=0x826f230) at connection.c:42
#18 0x08087a3e in ap_process_connection (c=0x826f230, csd=0x826f098)
    at connection.c:175
#19 0x08114eb7 in child_main (child_num_arg=0) at prefork.c:625
#20 0x08114f9a in make_child (s=0x8169970, slot=0) at prefork.c:665
#21 0x08115565 in ap_mpm_run (_pconf=0x81620a8, plog=0x81b21e8, s=0x8169970)
    at prefork.c:941
#22 0x0806a338 in main (argc=4, argv=0xbffff844) at main.c:703
(gdb) 
/******** end backtrace *****************/

error_log:
[Thu Jan 27 06:56:45 2005] [debug] mod_authnz_ldap.c(544): [client 192.168.1.9]
ldap authorize: Creating LDAP req structure

/*** But, if the process is allowed to finish, it will print this to the
error_log: ***/
[Thu Jan 27 07:02:06 2005] [debug] mod_authnz_ldap.c(556): [client 192.168.1.9]
auth_ldap authorise: User DN not found, ldap_search_ext_s() for user failed with
server down

/*** util_ldap.c (1109-1121) ***/ 

/* If the connection is already bound, return
    */
    if (ldc->bound)
    {
        ldc->reason = "LDAP: connection open successful (already bound)";
        return LDAP_SUCCESS;
    }
    /* try do the search */
    if ((result = ldap_search_ext_s(ldc->ldap,
				    (char *)basedn, scope,
                                    (char *)filter, attrs, 0, 
				    NULL, NULL,
                                    NULL, -1, &res)) == LDAP_SERVER_DOWN) {
        ldc->reason = "ldap_search_ext_s() for user failed with server down";
        goto start_over;
    }

If ldc->bound, then return LDAP_SUCCESS, but the connection is not returned...??
</snip>

I tried to track the problem down to its source, ( ;) ), but it is beyond me at
this time.  I figured you would probably be better equipped to see/fix the
issue, (if it really is one).

BTW, should apache2.1 bugs be sent to the dev@httpd.apache.org mailing list?

thanks :)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message