Bug 623036 – dev-libs/apr-1.6.2 change breaks htpasswd files

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description Hank Leininger 2017-06-29 18:14:18 UTC]

Created attachment 478346 [details, diff]
Revert the change in behavior of apr_file_transfer_contents which breaks htpasswd files.

Updating an htpasswd file with htpasswd(1) with dev-libs/apr-1.62 installed will break the file permissions on the htpasswd file, causing all access to content protected by htpasswd to fail.

I've just filed an upstream bug about this:

https://bz.apache.org/bugzilla/show_bug.cgi?id=61240

But a) Gentoo users bitten by this may search b.g.o first, and b) we can fix it in post.

A recent apr commit changed apr_file_transfer_contents to always set the destination file to match the permissions of the source file, even if the destination file already exists with different permissions.  htpasswd(1) (mis)uses this API call expecting the same behavior as it has always had: first a tempfile is created mode 600, and then apr_file_copy is used to copy contents to the real file.  

The first symptom admins will see is Apache errors like:

[Thu Jun 29 10:42:19.091228 2017] [authn_file:error] [pid 10048] (13)Permission denied: [client 127.0.0.1:57041] AH01620: Could not open password file: /path/to/htpasswd
[Thu Jun 29 10:49:19.448963 2017] [authn_file:error] [pid 9159] (13)Permission denied: [client 127.0.0.1:7209] AH01620: Could not open password file: /path/to/htpasswd
[Thu Jun 29 10:50:09.122301 2017] [authn_file:error] [pid 9317] (13)Permission denied: [client 127.0.0.1:9598] AH01620: Could not open password file: /path/to/htpasswd

I'll attach a patch that reverts the change, and an ebuild mod that uses that patch.

[Comment 1 Hank Leininger 2017-06-29 18:16:34 UTC]

Created attachment 478348 [details, diff]
ebuild patch to apply the apr_file_transfer_contents patch

[Comment 2 Hank Leininger 2017-07-18 16:03:11 UTC]

As an update on this, upstream concluded that this was a longstanding bug in how htpasswd / htdigest called libapr's apr_file_copy.  So they fixed those in apache-2.4.27, which has landed in portage by now.  Anybody running current versions of both dev-libs/apr and app-admin/apache-tools will not hit this problem.

I'm closing this bug, but it could still be that other users of dev-libs/apr that also happen to call apr_file_copy or apr_file_transfer_contents incorrectly.  I'll leave this here for possible future reference:

foo /usr/portage $ find . -type f -name \*.ebuild 2>/dev/null | xargs egrep -l 'dev-libs/apr' | cut -d/ -f2,3 | sort -u 
app-admin/apache-tools
app-admin/fsvs
app-i18n/tomoe
dev-java/netty-tcnative
dev-java/tomcat-native
dev-libs/apr-util
dev-libs/log4cxx
dev-libs/poco
dev-util/anjuta
dev-util/kdevplatform
dev-vcs/kdesvn
dev-vcs/qsvn
dev-vcs/rapidsvn
dev-vcs/rsvndump
dev-vcs/subversion
net-analyzer/nmap
net-libs/serf
sys-cluster/ganglia
www-apache/mod_perl
www-apache/mod_security
www-apache/mod_vhost_ldap
www-servers/nginx
xfce-extra/thunar-vcs-plugin

I made no effort to go into each of those packages, review their source and look for which apr_ functions they called and how.