Mailing-List: contact bugs-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apr.apache.org
From: bugzilla@apache.org
To: bugs@apr.apache.org
Subject: [Bug 61240] apr_file_transfer_contents change breaks htpasswd(1)
Date: Fri, 30 Jun 2017 21:04:54 +0000
Message-ID: <bug-61240-43213-4hSkQN5Zhw@https.bz.apache.org/bugzilla/>
In-Reply-To: <bug-61240-43213@https.bz.apache.org/bugzilla/>
References: <bug-61240-43213@https.bz.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
MIME-Version: 1.0
archived-at: Fri, 30 Jun 2017 21:05:01 -0000

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

Hank Leininger <hlein-apbz@korelogic.com> changed:

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

--- Comment #5 from Hank Leininger <hlein-apbz@korelogic.com> ---
(In reply to Ruediger Pluem from comment #4)
> IMHO APR code is now correct and this is a bug in  htpasswd.

Yes, I agree that htpasswd.c is using apr_file_copy incorrectly.  And has b=
een
doing so forever.

> Does the
> following patch to htpasswd fix the issue for you?
>=20
> Index: htpasswd.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- htpasswd.c  (revision 1800082)
> +++ htpasswd.c  (working copy)
> @@ -498,7 +498,7 @@
>=20
>      /* The temporary file has all the data, just copy it to the new
> location.
>       */
> -    if (apr_file_copy(dirname, pwfilename, APR_FILE_SOURCE_PERMS, pool) =
!=3D
> +    if (apr_file_copy(dirname, pwfilename, APR_OS_DEFAULT, pool) !=3D
>          APR_SUCCESS) {
>          apr_file_printf(errfile, "%s: unable to update file %s" NL,
>                          argv[0], pwfilename);

Indeed, that does seem to do the right thing.

So every caller of apr_file_copy or apr_file_transfer_contents ought to be
reviewed to make sure they are not using APR_FILE_SOURCE_PERMS flag (or
equivalent APR_FPROT_FILE_SOURCE_PERMS) when they do not mean it.

But in the meantime shouldn't the fix to apr_file_transfer_contents be
reverted, and instead announced as upcoming so projects that use libapr can
check?  Unless you can easily tell who all users of apr_file_copy /
apr_file_transfer_contents are, and can confirm that none of them will have
this problem leading to surprise failures.  That sounds a) not easy and b) =
not
the job of apr-developers?

Thanks!

--=20
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