LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   htpasswd no longer working after upgrade to 14.0 (http://www.linuxquestions.org/questions/slackware-14/htpasswd-no-longer-working-after-upgrade-to-14-0-a-4175454371/)

DaijoubuKun 03-16-2013 07:55 PM

htpasswd no longer working after upgrade to 14.0
 
Hello everyone, I'm having issues with htpasswd now that I have upgraded my server to Slackware 14.0 (worked fine in 13.1). When I generate a few user in a .htpasswd file, I cannot authenticate as that user, however, if I use htpasswd on another distribution and copy it over, it works fine.

I want to give a bit more information just to help ensure I'm giving good information.

I wish to add a simple level of authentication to view a stats page on my server. Not only myself, but others will need access. I can copy my username and password from a previous .htpasswd file and it works fine (from when I was running an older Slackware version), but when I try to use htpasswd now, no one can authenticate.

Here is the snippit from my apache config.

Code:

<Files "awstats.pl">
  AuthType Basic
  AuthName "Do you have a login?"
  AuthBasicProvider file
  AuthUserFile /srv/www/mydomain.com/.passwd.awstats
  Require valid-user
</Files>

The only thing I get in my apache error log in authentication failure to "file" Password Mismatch.

I know I'm pointing to the correct file since if I copy over a previous pass generated before the upgrade or on another distribution, it works great. Has anyone else ever ran into this one? I think it maybe an issue with the Apache 2.4.4 as the other disros I have used are running 2.2 and I have tried this on 5 different Slackware 14 (some 64bit, some 32) machines and I continue to have the same issue. Any help on this would be greatly appreciated. Thank you.

UPDATE: I have tried to do this with a couple other distros now (all running apache 2.2.x). And it seems the others use CRYPT by default (which works) and Slackware uses MD5 by default (which no longer works), but CRYPT fails when I try to force it in Slackware.

ljb643 03-16-2013 10:14 PM

Yes... just tried it and confirmed. Apache httpd (both the original 2.4.3 and newer 2.4.4) does not seem to work with basic authentication passwords encoded by htpasswd. It fails with crypt, MD5, and SHA methods. I don't know what is wrong, but the problem seems to be in htpasswd itself (as you found), not Apache httpd.

As a work-around, you can encode MD5 passwords (here "MyPassword") for your password file like this:
Code:

$ openssl passwd -apr1 MyPassword
Paste the result into your password file, putting "username:" in front. I tried this and it did work. But I would really like to know what is wrong with the htpasswd command, and why (per your post) it is only on Slackware 14.

MadMaverick9 03-17-2013 12:38 AM

I can confirm this too.

But ... when I specify the password on the command line with "-b" it works.

When I specify "-i" or the default password prompt, it is broken.

MadMaverick9 03-17-2013 01:06 AM

It's actually a bug in the upstream source:
Code:

diff -ur httpd-2.4.4-orig/support/passwd_common.c httpd-2.4.4/support/passwd_common.c
--- httpd-2.4.4-orig/support/passwd_common.c    2012-12-11 17:37:25.000000000 +0700
+++ httpd-2.4.4/support/passwd_common.c 2013-03-17 13:33:58.429462196 +0700
@@ -146,7 +146,6 @@
 int mkhash(struct passwd_ctx *ctx)
 {
    char *pw;
-    char pwin[MAX_STRING_LEN];
    char salt[16];
    apr_status_t rv;
    int ret = 0;
@@ -165,7 +164,7 @@
    else {
        if ((ret = get_password(ctx)) != 0)
            return ret;
-        pw = pwin;
+        pw = strdup(ctx->out);
    }
 
    switch (ctx->alg) {

When I made the above modification, it works. I could not find a bug in httpd's bugzilla. Hopefully somebody can confirm the bug and review my fix.

Update 4: this fixes it, but it's not right. The "get_password" function really should not put the password into "ctx->out", but into "ctx->passwd".

ponce 03-17-2013 01:45 AM

htpasswd has been refactored recently, can be something slipped/must be fixed: maybe it's better to file a bug upstream for this.

https://svn.apache.org/viewvc?view=r...vision=1420084

https://issues.apache.org/bugzilla/

DaijoubuKun 03-17-2013 02:01 AM

The first 2 replies, I can confirm as working.

Quote:

openssl passwd -apr1 MyPassword
and

Quote:

But ... when I specify the password on the command line with "-b" it works.
I have been trying some of the other distributions I have, but none of them are running Apache 2.4 yet, even in their experimental releases. So I haven't been able to test if this is a Slackware specific thing or not. However, after reviewing the Slackware build script in the source, I don't believe it is. Looks like we need to get this bug into Apache's tracker.

In the mean while, I have a single line script here that will allow anyone to create a new password without having to type it directly into the console. It's not elegant, but it works.

Code:

read -p "Username: " username; read -p "Password: " -s temppass; htpasswd -b .htpasswd $username $temppass
Add -c after -b if you are creating a new file.

MadMaverick9 03-17-2013 07:39 AM

Using "-b" is dangerous, because users can do a "ps" and see other user's passwords. So on a server where many users can login this is not a good idea.
Code:

/tmp/sb-httpd/httpd-2.4.4-orig/support/ > grep -i pwin passwd_common.* htpasswd.*
passwd_common.c:    char pwin[MAX_STRING_LEN];
passwd_common.c:        pw = pwin;

This is a little more than a slip. No value is ever assigned to "pwin".

I also checked the Apache HTTPD mailing lists (http://mail-archives.apache.org/mod_mbox/httpd-users/) and I could not find any mention of this bug. I searched for "htpasswd" in the subject lines.

ponce 03-17-2013 08:12 AM

maybe this is related

https://issues.apache.org/bugzilla/s...g.cgi?id=40243

if useful, the revisions involved for the changes to support/htpasswd.c and support/htdbm.c are

https://svn.apache.org/viewvc?view=r...vision=1420084
https://svn.apache.org/viewvc?view=r...vision=1420925
https://svn.apache.org/viewvc?view=r...vision=1455225

DaijoubuKun 03-17-2013 11:18 AM

Quote:

Originally Posted by MadMaverick9 (Post 4913294)
Using "-b" is dangerous, because users can do a "ps" and see other user's passwords. So on a server where many users can login this is not a good idea.

This is true, however, the other users better have incredible timing unless it takes the server a long time to generate a pass. It takes mine under one second, so any others who are logged in are not likely to see anything. The other benefit to that one-liner is the variables are only used until the end of execution then removed from memory. So there is not way to pull the variables or view your history to find the password.

ljb643 03-17-2013 01:32 PM

Quote:

Originally Posted by MadMaverick9 (Post 4913294)
...
Code:

/tmp/sb-httpd/httpd-2.4.4-orig/support/ > grep -i pwin passwd_common.* htpasswd.*
passwd_common.c:    char pwin[MAX_STRING_LEN];
passwd_common.c:        pw = pwin;

This is a little more than a slip. No value is ever assigned to "pwin".

It's OK - it is a pointer assignment. pw (the pointer) is assigned to point to the start of the pwin array.

There is a bug somewhere in here, but that isn't it.

The most likely culprit is that patch that was applied to 2.4.4 (found above by ponce) to add the -i option. I have a feeling htpasswd is now encrypting something other than the actual password, or perhaps the password with extra junk or truncated. It's kind of disturbing that something like that made it into a release and broke the most basic usage.

ljb643 03-17-2013 02:17 PM

Quote:

Originally Posted by ljb643 (Post 4913443)
It's OK - it is a pointer assignment. pw (the pointer) is assigned to point to the start of the pwin array.

Oops, sorry, my mistake. Seen in context of the code in passwd_common.c I can see that you are correct. It looks to me like it is hashing a bunch of random garbage (pw), because the password went somewhere else.

MadMaverick9 03-31-2013 02:14 AM

https://issues.apache.org/bugzilla/s...g.cgi?id=54735

Gnisho 05-10-2013 10:20 PM

Just ran afoul of this bug today. It's fixed upstream.

http://svn.apache.org/viewvc?view=re...vision=1465115

MadMaverick9 05-11-2013 12:21 AM

http://svn.apache.org/viewvc?view=re...vision=1476674

It was applied to the 2.4.x branch. So the next release of httpd, 2.4.5, will include the fix.


All times are GMT -5. The time now is 07:36 PM.