Hi, I get a segfault using following configuration: ------ httpd.conf ------ ServerName test User pgajdos Group users Listen 60080 PidFile /tmp/apache-rex/mod_auth_digest-Authorization/pid ErrorLog /tmp/apache-rex/mod_auth_digest-Authorization/error_log LoadModule auth_basic_module /usr/lib64/apache2-prefork/mod_auth_basic.so LoadModule dir_module /usr/lib64/apache2-prefork/mod_dir.so LoadModule authz_host_module /usr/lib64/apache2-prefork/mod_authz_host.so LoadModule auth_digest_module /usr/lib64/apache2-prefork/mod_auth_digest.so LoadModule authn_file_module /usr/lib64/apache2-prefork/mod_authn_file.so LoadModule authz_user_module /usr/lib64/apache2-prefork/mod_authz_user.so LoadModule version_module /usr/lib64/apache2-prefork/mod_version.so LoadModule authz_core_module /usr/lib64/apache2-prefork/mod_authz_core.so LoadModule authn_core_module /usr/lib64/apache2-prefork/mod_authn_core.so DocumentRoot /tmp/apache-rex/mod_auth_digest-Authorization/htdocs DirectoryIndex index.html ### example configuration # make sure shm file is written into writeable dir # (without that, I got Permission denied: AH01179: # balancer slotmem_create failed for 2.4.6 @ 13.1) # # see for details: # http://mail-archives.apache.org/mod_mbox/httpd-dev/201203.mbox/%3Cddf3855a-8ab3-45e1-9ad4-049d90ac8879@zimbra1%3E # # directive available from 2.4.2 <IfVersion >= 2.4.2> DefaultRuntimeDir /tmp/apache-rex/mod_auth_digest-Authorization/run </IfVersion> <Directory "/tmp/apache-rex/mod_auth_digest-Authorization/htdocs"> AuthType Digest AuthDigestProvider file AuthName "Restricted Area" AuthUserFile /tmp/apache-rex/mod_auth_digest-Authorization/htdigest AuthDigestDomain "/" Require valid-user </Directory> --------------------------- and curl command: $ curl -s -i -H "Authorization: Digest username=\"\", realm=\"\", nonce=\"\", uri=\"/index.html\", response=\"\", opaque=\"\"" http://localhost:60080/index.html run more than five times consecutively. It seems that client_list->table gets overwritten in add_client() for some reason: Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff1033522 in memcpy (__len=112, __src=0x7fffffffdb40, __dest=0x7ffff7f22008) at /usr/include/bits/string3.h:53 53 /usr/include/bits/string3.h: No such file or directory. (gdb) bt #0 0x00007ffff1033522 in memcpy (__len=112, __src=0x7fffffffdb40, __dest=0x7ffff7f22008) at /usr/include/bits/string3.h:53 #1 add_client (s=0x7ffff7f42bc8, info=0x7fffffffdb40, key=6) at mod_auth_digest.c:858 #2 gen_client (r=r@entry=0x7ffff7f040a0) at mod_auth_digest.c:1117 #3 0x00007ffff10357d8 in note_digest_auth_failure (r=r@entry=0x7ffff7f040a0, conf=conf@entry=0x7ffff7f3c188, resp=resp@entry=0x7ffff7f05810, stale=stale@entry=0) at mod_auth_digest.c:1262 #4 0x00007ffff10359e2 in authenticate_digest_user (r=0x7ffff7f040a0) at mod_auth_digest.c:1846 [...] (gdb) frame 1 #1 add_client (s=0x7ffff7f42bc8, info=0x7fffffffdb40, key=6) at mod_auth_digest.c:858 858 memcpy(entry, info, sizeof(client_entry)); (gdb) p client_list->table $1 = (client_entry **) 0x0 (gdb) p client_list $8 = (struct hash_table *) 0x7ffff7f22038 (gdb) p entry $9 = (client_entry *) 0x7ffff7f22008 (gdb) p sizeof(client_entry) $10 = 112 (gdb) Unfortunately I have not learned the aim of the opaque code in note_digest_auth_failure() to be able to think about a patch. When I run just: $ curl -i http://localhost:60080/index.html I got 401 correctly but gen_client()/add_client() is not called at all. During the first curl command (with the opaque= in the header) these two are called.
(In reply to Petr Gajdos from comment #0) > Unfortunately I have not learned the aim of the opaque code in > note_digest_auth_failure() to be able to think about a patch. When I run > just: > > $ curl -i http://localhost:60080/index.html > > I got 401 correctly but gen_client()/add_client() is not called at all. > During the first curl command (with the opaque= in the header) these two are > called. In other words: if you look at example flow (run.sh) in: https://github.com/pgajdos/apache-rex/tree/master/mod_auth_digest-Authorization There is 'opaque=' parameter nowhere in 'Authentication-Info' header in 200-response. So I am just not sure when opaque= (~ number of client here?) parameter is sent to client; note_digest_auth_failure()'s code seems to heavily depend on its value trough resp->opaque, which is set only while parsing Authorization: header, if I understand correctly.
Could be a dup of bug 55284. t least, add_client(...) looks involved in both cases.