search for: t_strdup_noconst

Fancy, while not fun. :-) But thanks, that does work. Doing that, n?ing over calls to strcmp, it failed: passdbs_init () at passdb.c:313 313 passdb_register_module(&passdb_ldap); (gdb) passdb_register_module (iface=0x280120) at passdb.c:33 33 old_iface = passdb_interface_find(iface->name); (gdb) passdb_interface_find (name=0x16fe60 "ldap") at passdb.c:20 20

...with qmail's POP3 daemon to verify vchkpw would fill the table correcly. But I'm not sure how to get dovecot to do it: I know this is close, but there is something not right in src/auth/userdb-vpopmail.c line 99. vset_lastauth(vpop_user, vpop_domain, &auth_request->remote_ip, t_strdup_noconst(auth_request->service)); I'm, by far, NOT a C programmer - Feel free to laugh at my code publicly :) Thanks, Rick

...equest->service); password = NULL; *result_r = PASSDB_RESULT_USER_DISABLED; } else { if (vpw->pw_clear_passwd != NULL && *vpw->pw_clear_passwd != '\0') { password = t_strdup_noconst(vpw->pw_clear_passwd); *cleartext = TRUE; } else if (!*cleartext) password = t_strdup_noconst(vpw->pw_passwd); else password = NULL; *result_r = password != NULL ?...

Quoting Aki Tuomi <aki.tuomi at open-xchange.com>: > On 03.10.2018 23:30, Eric Broch wrote: >> Hello list, >> >> I run Dovecot with the vpopmail driver and have found that it >> authenticates against the clear text password in the vpopmail >> database. Is there a configuration option either at compile time, link >> time, or a setting in one of the

...password = NULL; >> *result_r = PASSDB_RESULT_USER_DISABLED; >> } else { >> if (vpw->pw_clear_passwd != NULL && >> *vpw->pw_clear_passwd != '\0') { >> password = t_strdup_noconst(vpw->pw_clear_passwd); >> *cleartext = TRUE; >> } else if (!*cleartext) >> password = t_strdup_noconst(vpw->pw_passwd); >> else >> password = NULL; >>...

...th_request->service); password = NULL; *result_r = PASSDB_RESULT_USER_DISABLED; } else { if (vpw->pw_clear_passwd != NULL && *vpw->pw_clear_passwd != '\0') { password = t_strdup_noconst(vpw->pw_clear_passwd); *cleartext = TRUE; } else if (!*cleartext) password = t_strdup_noconst(vpw->pw_passwd); else password = NULL; *result_r = password != NULL ? PAS...

...password = NULL; > *result_r = PASSDB_RESULT_USER_DISABLED; > } else { > if (vpw->pw_clear_passwd != NULL && > *vpw->pw_clear_passwd != '\0') { > password = t_strdup_noconst(vpw->pw_clear_passwd); > *cleartext = TRUE; > } else if (!*cleartext) > password = t_strdup_noconst(vpw->pw_passwd); > else > password = NULL; > *res...

...LL; >>> ? ? ? ? ? ? ? ?*result_r = PASSDB_RESULT_USER_DISABLED; >>> ? ? ? ?} else { >>> ? ? ? ? ? ? ? ?if (vpw->pw_clear_passwd != NULL && >>> ? ? ? ? ? ? ? ? ? ?*vpw->pw_clear_passwd != '\0') { >>> ? ? ? ? ? ? ? ? ? ? ? ?password = t_strdup_noconst(vpw->pw_clear_passwd); >>> ? ? ? ? ? ? ? ? ? ? ? ?*cleartext = TRUE; >>> ? ? ? ? ? ? ? ?} else if (!*cleartext) >>> ? ? ? ? ? ? ? ? ? ? ? ?password = t_strdup_noconst(vpw->pw_passwd); >>> ? ? ? ? ? ? ? ?else >>> ? ? ? ? ? ? ? ? ? ? ? ?password = NU...

...---- return str_c(str); } + static int create_directories(const char *directory, mode_t mask) + { + char *chunk, *slash, *path; + mode_t oldmask; + int result; + + if (mkdir(directory, 0777) == 0 || errno == EEXIST) + return TRUE; + + if (errno != ENOENT) + return FALSE; + + path = t_strdup_noconst(directory); + + oldmask = umask(mask); + + for (chunk = path; (slash = strchr(chunk, '/')); chunk = slash + 1) { + + if (slash > chunk) { + + *slash = '\0'; + result = mkdir(path, 0777); + *slash = '/'; + + if (result != 0 && errno != EEXIST) { +...

...e the value to some memory region. Can you see if this following patch fixes it? Aki > On October 17, 2016 at 4:14 PM Pierre Jaury <pierre at jaury.eu> wrote: > > > Okay, it seems to me that the bug is due to "t_str_tabunescape" using > the unsafe datastack ("t_strdup_noconst") while the string is actually > returned in an async callback. > > Before it is handled by "client_dict_lookup", "client_dict_wait" > actually fires some IO loops that are more than likely to call "t_pop" > and free/flush the result string (I chec...

...tore, const char *ca, - STACK_OF(X509_NAME) **xnames_r) +static void load_ca(SSL_CTX *ssl_ctx, const char *ca) { - /* mostly just copy&pasted from X509_load_cert_crl_file() */ - STACK_OF(X509_INFO) *inf; - X509_INFO *itmp; - X509_NAME *xname; - BIO *bio; - int i; - - bio = BIO_new_mem_buf(t_strdup_noconst(ca), strlen(ca)); - if (bio == NULL) - i_fatal("BIO_new_mem_buf() failed"); - inf = PEM_X509_INFO_read_bio(bio, NULL, NULL, NULL); - if (inf == NULL) - i_fatal("Couldn't parse ssl_ca: %s", ssl_last_error()); - BIO_free(bio); - - if (xnames_r != NULL) { - *xnames_r = sk_X5...

...xes it? > > > > Aki > > > >> On October 17, 2016 at 4:14 PM Pierre Jaury <pierre at jaury.eu> wrote: > >> > >> > >> Okay, it seems to me that the bug is due to "t_str_tabunescape" using > >> the unsafe datastack ("t_strdup_noconst") while the string is actually > >> returned in an async callback. > >> > >> Before it is handled by "client_dict_lookup", "client_dict_wait" > >> actually fires some IO loops that are more than likely to call "t_pop" > >&...

While trying to isolate properly and reproduce, I was able to trigger the same bug with the following code: struct dict *dict; char* dict_uri = "proxy::sieve"; char* key = "priv/key"; char* username = "admin at domain.tld"; char* value, error; dict_drivers_register_builtin(); dict_init(dict_uri, DICT_DATA_TYPE_STRING, username,

...es' .libs/libssl_iostream_openssl.so: undefined reference to `o_stream_get_name' .libs/libssl_iostream_openssl.so: undefined reference to `i_stream_read_data' .libs/libssl_iostream_openssl.so: undefined reference to `i_info' .libs/libssl_iostream_openssl.so: undefined reference to `t_strdup_noconst' .libs/libssl_iostream_openssl.so: undefined reference to `i_stream_get_error' .libs/libssl_iostream_openssl.so: undefined reference to `o_stream_get_buffer_avail_size' .libs/libssl_iostream_openssl.so: undefined reference to `t_strndup' .libs/libssl_iostream_openssl.so: undefined...

Hi! This does sound like a bug, we'll have look. Aki On 17.10.2016 01:26, Pierre Jaury wrote: > I dived a little bit further into the rabbit hole, up to the point where > debugging has become unpracticle but I still haven't found the root > cause for sure. > > I read most of the code for "p_strdup" based on datastack memory pools > (which are used for