[16949] in Kerberos_V5_Development
Re: Notes on lost extended error messages for kinit -k
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Thu Jun 30 10:26:07 2011
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: krbdev@mit.edu
Message-ID: <4E0C8777.4070408@secure-endpoints.com>
Date: Thu, 30 Jun 2011 10:25:59 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: krbdev@mit.edu
In-Reply-To: <201106300520.p5U5KumR004300@outgoing.mit.edu>
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============1761466010=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1761466010==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigB145BF9E4ADD0EB158213E6F"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB145BF9E4ADD0EB158213E6F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 6/30/2011 1:20 AM, ghudson@MIT.EDU wrote:
> * Perhaps krb5_get_init_creds_keytab() should save the error message
> before the retry, and put it back if it decides to use ret instead
> of ret2. Perhaps we want convenience functions to make this easier
> to do.
>=20
I think it is the responsibility of code such as this to save context
and restore it as necessary.
The krb5_get_init_creds_keytab() case is flawed for another reason. The
force retry to master call is made regardless of whether or not there is
a master defined. As a result it is impossible for
krb5_get_init_creds_keytab() to know whether or not the error state from
the second call is more or less meaningful than the first.
If this code were to be restructured, I would have a function that
determines whether or not there are masters defined and only make the
second call if there are. Secondly, the master list should be cached so
that the cost of dns lookups is not repeated.
Jeffrey Altman
--------------enigB145BF9E4ADD0EB158213E6F
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)
iQEcBAEBAgAGBQJODId5AAoJENxm1CNJffh4PhMIALvBk1x0W/jZZfj2CYyzsg0f
eS77q7ec9fyr2EcBd2Z6aMvOe2feRqYVl6qSG6TUkWivvBCd5uS64s5qbzpTs5bp
+XXtZqa0NEfgBanSdzgOQhKDcKs3QE6wy0sJTbfOofnFR3Xn5bjyLOW/0Dz+LoTB
csDnAtSwxi8r9RzHKVDK2OG+O1ZqT+bOJzA334PFAgXxnGpD7lFTKtMPLlGqX4P/
k3llwMPR9938LC9zwendqz9sadsZshkDrwBFx1vxaycGmC0OiEFsBGV9HrEfmFS+
qxL6P55ihZFp8bXv5RZg0jakzcRkhMe8dZnhOBbIP1nJcBgkjvuodx3TWpmcqH4=
=wf4T
-----END PGP SIGNATURE-----
--------------enigB145BF9E4ADD0EB158213E6F--
--===============1761466010==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============1761466010==--
