Bug 55086 - htpasswd produces non-functional entry in .htpasswd file if not used with -b option
Summary: htpasswd produces non-functional entry in .htpasswd file if not used with -b ...
Status: RESOLVED DUPLICATE of bug 54735
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_auth (show other bugs)
Version: 2.4.4
Hardware: Sun Solaris
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2013-06-09 17:34 UTC by Dennis Clarke
Modified: 2013-06-10 18:43 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Clarke 2013-06-09 17:34:56 UTC
This took a bit of trial and error to prove to myself that I 
was seeing something consistent. 

A little introduction to the situation : 

core# uname -a 
SunOS trend-core 5.10 Generic_148888-01 sun4v sparc SUNW,T5240
core# cat /etc/release
                   Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
  Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.
                            Assembled 23 August 2011

core# pwd
core# ls -lap httpd.conf 
-rw-r--r--   1 webservd webservd   26352 Jun  7 01:33 httpd.conf

In that httpd.conf file I have the following : 

# Deny access to the entirety of your server's filesystem. You must
# explicitly permit access to web content directories in other
# <Directory> blocks below.
<Directory />
    Options -Indexes

    AllowOverride None
    AllowOverrideList None
    Require group appuser
    AuthType Basic
    AuthName "core.myservername.com"
    AuthBasicProvider file
    AuthUserFile /usr/local/www/conf/.htpasswd
    AuthGroupFile /usr/local/www/conf/.htgroup

n.b.: I edited the "AuthName" data for this bug entry.

I create a new user in the /usr/local/www/conf/.htpasswd file with 
the /usr/local/bin/htpasswd tool thus : 

core# /usr/local/bin/htpasswd /usr/local/www/conf/.htpasswd testuser    
New password: 
Re-type new password: 
Adding password for user testuser

The password that I enter is f00bar where those are zero digits.

The entry in the .htpasswd file looks like so : 

core# grep testuser /usr/local/www/conf/.htpasswd

I edit .htgroup to ensure that "testuser" is in the "appuser" group thus :

core# grep "testuser" .htgroup
appuser: dclarke testuser

I even verify that there are no special characters in there or utf8 
and I do this because that user simply won't be allowed to auth : 

core# grep "testuser" .htgroup | od -Ax -t x1 
0000000 61 70 70 75 73 65 72 3a 20 64 63 6c 61 72 6b 65
0000010 20 74 65 73 74 75 73 65 72 0a

This looks correct to me. 

I then try to login to the Apache server as the user "testuser" with
the password "f00bar" and get a 401 Unauthorized error. I test with
both FireFox and Opera browsers.  I am able to login as myself with
username "dclarke" just fine. 

Here is what I see in the ssl_error_log : 

/usr/local/www/var/logs/ssl_error_log:[Sun Jun 09 17:09:16.964401 2013] [auth_basic:error] [pid 11193:tid 22] [client xxx.xxx.xxx.xxx:47811] AH01617: user testuser: authentication failure for "/cgi-bin/debug_cgi": Password Mismatch

I then try this, which should not be needed, however I try it : 

core# /usr/local/bin/apachectl graceful

This results in no change. 

I then try, out of sheer luck and frustration, this approach to using 
the htpasswd tool : 

core# /usr/local/bin/htpasswd -b /usr/local/www/conf/.htpasswd testuser f00bar
Updating password for user testuser
core# grep testuser /usr/local/www/conf/.htpasswd

I am now able to login/auth as the user "testuser" just fine. 

I ran into this because users I was trying to add to the .htpasswd
file simply could not login and it was out of sheer luck that I 
tried the "-b" option and saw that it works.  Not sure why. 

I could try to single step into the htpasswd process if needed as
I compiled everything with Oracle Studio 12.3 and with -g and full
debug symbols. 

One other item to point out, if I do this, I get the ability to auth
as the testuser just fine : 

core# grep -v "testuser" .htpasswd > foo ; mv foo .htpasswd
core# /usr/local/bin/htpasswd -b /usr/local/www/conf/.htpasswd testuser f00bar
Adding password for user testuser

Feels like, and this is just a WAG ( Wild A++ Guess ) that the input
of the password read from stdin is not at all a match with the argv[4]
parameter provided on the command line above. Would love to insert a
printf ( foo ); into htpasswd at the correct place to verify that WAG.

The following info may also be helpful : 

core# /usr/local/bin/httpd -V
Server version: Apache/2.4.4 (Unix)
Server built:   Feb 28 2013 10:46:58
Server's Module Magic Number: 20120211:11
Server loaded:  APR 1.4.6, APR-UTIL 1.5.1
Compiled using: APR 1.4.6, APR-UTIL 1.5.1
Architecture:   64-bit
Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D HTTPD_ROOT="/usr/local"
 -D SUEXEC_BIN="/usr/local/bin/suexec"
 -D DEFAULT_PIDLOG="www/var/logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="www/conf/mime.types"
 -D SERVER_CONFIG_FILE="www/conf/httpd.conf"

core# grep "^LoadModule" httpd.conf 
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_anon_module modules/mod_authn_anon.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule file_cache_module modules/mod_file_cache.so
LoadModule cache_module modules/mod_cache.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
LoadModule reqtimeout_module modules/mod_reqtimeout.so
LoadModule ext_filter_module modules/mod_ext_filter.so
LoadModule include_module modules/mod_include.so
LoadModule filter_module modules/mod_filter.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule mime_module modules/mod_mime.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule logio_module modules/mod_logio.so
LoadModule env_module modules/mod_env.so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule usertrack_module modules/mod_usertrack.so
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule version_module modules/mod_version.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule unixd_module modules/mod_unixd.so
LoadModule dav_module modules/mod_dav.so
LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule info_module modules/mod_info.so
LoadModule suexec_module modules/mod_suexec.so
LoadModule cgid_module modules/mod_cgid.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule actions_module modules/mod_actions.so
LoadModule speling_module modules/mod_speling.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule php5_module modules/libphp5.so
LoadModule ssl_module modules/mod_ssl.so

The cgi binary that I hit as the user "testuser" gives me a pile of 
cgi environment variables, these may not be of use but they prove 
that I am authenticating as the correct user with basic auth : 

Output to browser Opera from debug_cgi : 
 cgiAUTH_TYPE: Basic
 cgiCONTEXT_DOCUMENT_ROOT: /usr/local/www/data/cgi-bin/
 cgiCONTEXT_PREFIX: /cgi-bin/
 cgiDOCUMENT_ROOT: /usr/local/www/data/htdocs
 cgiHTTPS: on
 cgiHTTP_ACCEPT: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
 cgiHTTP_ACCEPT_ENCODING: gzip, deflate
 cgiHTTP_ACCEPT_LANGUAGE: en-CA,en;q=0.9
 cgiHTTP_CACHE_CONTROL: no-cache
 cgiHTTP_HOST: core.myservername.com
 cgiHTTP_USER_AGENT: Opera/9.80 (X11; Linux x86_64) Presto/2.12.388 Version/12.15
 cgiLD_LIBRARY_PATH: /usr/local/lib
 cgiPATH: /usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/SUNWspro/bin:/sbin:/bin:/usr/sbin:/usr/openwin/bin:/usr/dt/bin:/usr/X11/bin:/opt/schily/bin
 cgiContentLength: NULL
 cgiREMOTE_ADDR: xxx.xxx.xxx.xxx
 cgiREMOTE_PORT: 47915
 cgiREMOTE_USER: testuser
 cgiREQUEST_URI: /cgi-bin/debug_cgi
 cgiSCRIPT_FILENAME: /usr/local/www/data/cgi-bin/debug_cgi
 cgiSCRIPT_NAME: /cgi-bin/debug_cgi
 cgiSERVER_ADDR: yyy.yyy.yyy.yyy
 cgiSERVER_ADMIN: dclarke@blastwave.org
 cgiSERVER_NAME: core.myservername.com
 cgiSERVER_PORT: 443
 cgiSERVER_SIGNATURE: <address>Apache/2.4.4 (Unix) OpenSSL/1.0.1e PHP/5.4.15 Server at core.myservername.com Port 443</address>
 cgiSERVER_SOFTWARE: Apache/2.4.4 (Unix) OpenSSL/1.0.1e PHP/5.4.15
 cgiSSL_SERVER_A_KEY: rsaEncryption
 cgiSSL_SERVER_A_SIG: sha1WithRSAEncryption
 cgiSSL_SERVER_I_DN: CN=VeriSign Class 3 Extended Validation SSL CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US
 cgiSSL_SERVER_I_DN_CN: VeriSign Class 3 Extended Validation SSL CA
 cgiSSL_SERVER_I_DN_O: VeriSign, Inc.
 cgiSSL_SERVER_I_DN_OU: VeriSign Trust Network
 cgiSSL_SERVER_I_DN_OU_1: Terms of use at https://www.verisign.com/rpa (c)06
.  etc etc lots of SSL and Verisign info
 cgiSSL_SERVER_V_END: Feb  4 23:59:59 2015 GMT
 cgiSSL_SERVER_V_START: Feb  4 00:00:00 2013 GMT
 cgiSSL_SESSION_ID: EF53580D357C3A6DE71EF97B38530D3A4155D500E0DE171FB2FA5A3A3E62D659
 cgiSSL_VERSION_INTERFACE: mod_ssl/2.4.4
 cgiTZ: GMT0

If there is something I can do to track this down or data to provide
I would be glad to try. 

Dennis Clarke
Comment 1 Stefan Fritsch 2013-06-09 20:20:41 UTC

*** This bug has been marked as a duplicate of bug 54735 ***
Comment 2 Dennis Clarke 2013-06-10 18:43:34 UTC
tested and documented on Solaris 10 Niagara servers with Oracle Studio 12.3 tools .. 

see details at bottom of bug54735