apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 61240] apr_file_transfer_contents change breaks htpasswd(1)
Date Fri, 30 Jun 2017 03:25:37 GMT
https://bz.apache.org/bugzilla/show_bug.cgi?id=61240

hlein-apbz@korelogic.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

--- Comment #3 from hlein-apbz@korelogic.com ---
(In reply to Nick Kew from comment #2)
> The change sets file perms to those of the source file if and only if the
> to_perms argument tells it to.  So if there's a bug, it's in the arguments
> with which apr_file_transfer_contents is called.

Yeah, probably htpasswd(1) is calling apr_file_copy incorrectly, but it has
been doing so forever:

apache-git/httpd $ git blame support/htpasswd.c | egrep apr_file_copy
9229359a77b (Thom May           2004-03-13 22:18:19 +0000 506)     if
(apr_file_copy(dirname, pwfilename, APR_FILE_SOURCE_PERMS, pool) !=

It does seem like APR_FILE_SOURCE_PERMS is the wrong value to pass here, and it
has worked all along only because of the actual behavior of apr_file_copy. 
Fixing apr_file_copy broke this longstanding wrong use - and perhaps other
callers of it also have baked-in assumptions of its wrong behavior.

I only see two callers of apr_file_copy in httpd.git, htpasswd.c and
htdigest.c; the latter is very similar especially in its file-handling code.

I have no idea what other Apache projects link to libapr and might also
(mis)use it and whose bugs this change will now trigger.

> I just tried running htpasswd under gdb with a breakpoint on
> apr_file_transfer_contents, but it never reached the breakpoint.  Can you
> supply a test case that demonstrates your problem?

Hm, strange.  It is 100% reproducible here.  Using strace since I am garbage
with gdb, and batch mode (-b) to simplify the example (has no impact on the bad
behavior by htpasswd):

# ldd `which htpasswd` | egrep apr-
        libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x000003072eec4000)

# ls -l /usr/lib64/libapr-1.so.0
lrwxrwxrwx 1 root root 17 Jun 29 12:41 /usr/lib64/libapr-1.so.0 ->
libapr-1.so.0.6.2

# umask
0022

# ls -l test_htpasswd
-rw-r----- 1 root apache 47 Jun 29 23:06 test_htpasswd

# strace htpasswd -b -m test_htpasswd testuser testpass 2>&1 | egrep -2
'chmod|O_CREAT'
read(3, "\26\341$D", 4)                 = 4
close(3)                                = 0
open("/tmp/apr-tmp.xwEPYS", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
fcntl(3, F_GETFD)                       = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
--
close(3)                                = 0
unlink("/tmp/apr-tmp.xwEPYS")           = 0
open("/tmp/htpasswd.tmp.4fZ6Oj", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
fcntl(3, F_GETFD)                       = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
--
open("/tmp/htpasswd.tmp.4fZ6Oj", O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0600, st_size=47, ...}) = 0
chmod("test_htpasswd", 0600)            = 0
open("test_htpasswd", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0600) = 5
read(4, "testuser:$apr1$qXiIfnVS$aGBhoQeU"..., 8192) = 47
write(5, "testuser:$apr1$qXiIfnVS$aGBhoQeU"..., 47) = 47


# ls -l test_htpasswd
-rw------- 1 root apache 47 Jun 29 23:08 test_htpasswd

First a tempfile is created mode 0600 (good, sane).  Then a second, also mode
0600.  Then that second is fstat'ed, and the existing htpasswd file is chmod'ed
with the specific perms from that second tempfile.

Tested using htpasswd(1) from both Apache 2.2.mumble and 2.4.26; the relevant
part of support/htpasswd.c is unchanged, as shown above.

Please let me know if this is not enough to reproduce.

Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


Mime
View raw message