-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/15/2013 11:50 AM, Stephen Gallagher wrote:
There was duplicated code in cc_file_check_existing() and in
cc_dir_check_existing(). I pulled them into the same function.
There are two changes made to the original code here: 1) Fixes a
use-after-free bug in cc_file_check_existing(). In the original
code, we called krb5_free_context() and then used that context
immediately after that in krb5_cc_close(). This patch corrects the
ordering
2) The krb5_cc_resolve() call handles KRB5_FCC_NOFILE for all cache
types. Previously, this was only handled for DIR caches.
This second part I need someone with Kerberos knowledge to verify.
Is there a risk of receiving this error for the FILE or KEYRING
types, and if so is this handling still acceptable or should they
be special-cased?
Self-nack. New patch attached (I was never actually returning the
validity result).
Interdiff:
diff --git a/src/providers/krb5/krb5_utils.c
b/src/providers/krb5/krb5_utils.c
index 47c45d0..8166435 100644
- --- a/src/providers/krb5/krb5_utils.c
+++ b/src/providers/krb5/krb5_utils.c
@@ -750,6 +750,7 @@ check_cc_validity(const char *location,
}
ret = EOK;
+ *_valid = valid;
done:
if (ccache) krb5_cc_close(context, ccache);
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlIWHAwACgkQeiVVYja6o6O4qACdFs9NjmjFD0oq2A3cWkjvbCOT
CSEAn3h+SB/T8H1OguTueRY+UfafjJ/b
=wxng
-----END PGP SIGNATURE-----