[33532] in Kerberos
Re: Win32 bug in krb5_rc_io_destroy
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Fri Jul 1 09:14:38 2011
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kerberos@mit.edu
Message-ID: <4E0DC82E.9080109@secure-endpoints.com>
Date: Fri, 01 Jul 2011 09:14:22 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: kerberos@mit.edu
In-Reply-To: <77063e02-8764-405f-a613-95955d8bc582@q14g2000prh.googlegroups.com>
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============0697329156=="
Errors-To: kerberos-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0697329156==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigB99B84CDD157827E0430E2DC"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB99B84CDD157827E0430E2DC
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
This is just one symptom of a more fundamental bug. The replay cache
code as implemented is full of race conditions because of the reliance
on the C Run time library file operations instead of native Win32
operations. In addition to not permitting files to be opened with the
correct share modes, they cannot be opened with the correct access
control lists. The RTL operations have the same names as those on Unix
but they do not have the same behaviors. unlink() is a perfect example.
Small patches to the replay cache will not create a replay cache that is
safe to use on Windows. Instead a new Windows specific implementation
is required.
Jeffrey Altman
On 7/1/2011 2:31 AM, checker wrote:
>=20
> Hi, the unlink(d->fn) at the top of krb5_rc_io_destroy fails on Win32
> because the file was opened without FILE_SHARE_DELETE (since it's
> opened through _open there's actually no way to set that flag without
> marking it a temporary file), so I patched it to close the file
> first. I assume this is a bug? I also assume no one noticed this
> since most of the code calls krb5_rc_close rather than
> krb5_rc_destroy? I found it while getting sim_client.c to work with
> my build.
>=20
> Should I file a bug, or is this enough (the bug list says to post here
> first)?
>=20
> Thanks,
> Chris
>=20
> =3D=3D=3D modified file 'src/lib/krb5/rcache/rc_io.c'
> --- src/lib/krb5/rcache/rc_io.c 2011-04-09 08:50:00 +0000
> +++ src/lib/krb5/rcache/rc_io.c 2011-07-01 06:18:12 +0000
> @@ -481,6 +481,13 @@
> krb5_error_code
> krb5_rc_io_destroy(krb5_context context, krb5_rc_iostuff *d)
> {
> +#if defined(_WIN32)
> + // the file isn't opened with FILE_SHARE_DELETE so we need to
> close it first
> + if(close(d->fd) =3D=3D -1) {
> + return KRB5_RC_IO_UNKNOWN;
> + }
> + d->fd =3D -1;
> +#endif
> if (unlink(d->fn) =3D=3D -1)
> switch(errno)
> {
>=20
>=20
>=20
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--------------enigB99B84CDD157827E0430E2DC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iQEcBAEBAgAGBQJODcgzAAoJENxm1CNJffh43NsIAK7LdiiFslMU1tnwlCrX1YpE
OGNu/lAbbuBsKFY4KD+5yWlkv96vMQTbyazGBTDVWj98uJlEUQ3uzI1Q0fQSM3x+
IxotRnvubBIOnYjgDfndBrM+GKWp1r587VWuvTnt8XYQWRZbHXQ4esO+VuhC9Zmk
vNa/Hn4POf/eFFp4ZBn6NZ0Uv2u7a4OzyT4IZw6sGvOKCjF53NOXZ2BrXrfVYjF4
CUMcZA+FveF/lhU0BYpKBV/bx21vrsXbdzt8Adit3MoK9z29xcQqrQWtjuQ79hQj
Q8G0+6tTQ9n+3NmJkCgnQdVkVffsCXTH8g1GOUHQbZcEMHDzBOZNeCplb+jCkCM=
=3m59
-----END PGP SIGNATURE-----
--------------enigB99B84CDD157827E0430E2DC--
--===============0697329156==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============0697329156==--
