search for: ldap_request

...DAP_AUTH_SIMPLE); if (msgid == -1) { - db_ldap_connect_finish(conn, ldap_get_errno(conn)); + if (db_ldap_connect_finish(conn, ldap_get_errno(conn)) < 0) { + /* lost connection, close it */ + ldap_conn_close(conn, TRUE); + } i_free(ldap_request); return -1; }

...n_auth_continue' function is passed as an argument in the 'auth_request_verify_plain' function which, in turns pass it to the function pointed to by 'passdb->verify_plain' (that is 'ldap_verify_plain') which doesn't use it [instead maybe of setting the 'passdb_ldap_request' 'password' field with it ?]. So once back from the LDAP request, when in 'handle_request' we call 'password_verify', the password we try to match against the one read in the LDAP db is null. Did I get it right ? Thanks -- Thomas Hummel | Institut Pasteur <h...

...() from /lib/libc.so.5 No symbol table info available. #6 0x1827a513 in ldexp () from /lib/libc.so.5 No symbol table info available. #7 0x1827a644 in free () from /lib/libc.so.5 No symbol table info available. #8 0x080502c7 in ldap_input (context=0x2c) at db-ldap.c:172 request = (struct ldap_request *) 0x806a580 timeout = {tv_sec = 0, tv_usec = 0} res = (LDAPMessage *) 0x806a5a0 ret = 0 msgid = 405650150 #9 0x0805cea8 in io_loop_handler_run (ioloop=0x8075340) at ioloop-poll.c:184 data = (struct ioloop_handler_data *) 0x806a160 pollfd = (struct p...

...9a7f1 in auth_request_verify_plain_callback (result=<optimized out>, request=0x55c932881628) at auth-request.c:1193 passdb = <optimized out> __func__ = "auth_request_verify_plain_callback" #16 0x00007f279faaa0dc in ldap_lookup_finish (res=<optimized out>, ldap_request=0x55c93287d250, auth_request=0x55c932881628) at passdb-ldap.c:112 passdb_result = PASSDB_RESULT_USER_UNKNOWN ret = <optimized out> password = 0x0 scheme = <optimized out> #17 ldap_lookup_pass_callback (conn=<optimized out>, request=0x55c93287d250, r...

...796d0 "/usr/local/dovecot/etc/dovecot-ldap.conf") at userdb-ldap.c:208 208 (void)db_ldap_connect(userdb_ldap_conn); (gdb) p passdb_ldap_conn->attr_names[1] $2 = 0x80799e0 "homeDirectory" (gdb) cont Continuing. Breakpoint 3, ldap_lookup_pass (auth_request=0x5, ldap_request=0x14) at passdb-ldap.c:157 157 struct ldap_connection *conn = passdb_ldap_conn; (gdb) p passdb_ldap_conn->attr_names[1] $3 = 0x80799e0 "homeDirectory" (gdb) cont Continuing. -- Could it explain why I get - in the error log : -- dovecot: Apr 08 18:08:15 Error: auth(defa...

..., separator=0x8067b1a ",") at strfuncs.c:571 alloc_len = 8 sep_len = 1 len = 9 pos = 39 needed_space = 0 str = 0x806e488 "uid,homeDirectory,,,uidNumber,gidNumber" #1 0x080578a1 in ldap_lookup_pass (auth_request=0x8077a10, ldap_request=0x8077ab0) at passdb-ldap.c:181 conn = (struct ldap_connection *) 0x807a810 vars = (const struct var_expand_table *) 0x807a9a0 attr_names = (const char **) 0x807aa08 filter = 0x806e268 "(&(objectClass=posixAccount)(uid=dovetest))" base = 0x806e4...

Just thought I'd mention that I probably won't be answering mails very actively this week while I'm in San Antonio (and I was kind of busy last week too). Hopefully I'll get back to answering/bugfixing next week.. I also started writing developers documentation to http://wiki.dovecot.org/Design. Comments welcome. Some things I had planned next: - istream internals - lib-storage

Hi, currently we deploying Dovecot as imap/pop3 proxy. Every few minutes some panic/assert occurred (we connect roughly 7k - 8k user at one imap proxy with a connection rate of 200/s). We activate core dumps. Concerning the sensitive information in the dump we would prefer to not share the dump (e.g. i found our ssl private key in the dump). Log/Stack trace: Mar 30 15:54:06 imap16 dovecot: