Proposed modifications to replay cache to prevent false positives
Nicolas Williams
Nicolas.Williams at sun.com
Thu May 22 00:06:30 EDT 2008
On Wed, May 21, 2008 at 11:41:01PM -0400, Henry B. Hotz wrote:
> On May 21, 2008, at 12:02 AM, krbdev-request at mit.edu wrote:
> > I think part of the intent in this project was to retain backwards
> > compatibility with the existing implementation in terms of the on-disk
> > format. (E.g., mixing OS-vendor and MIT binaries without breaking
> > ...
>
> Is there a real example where this is useful? I can't, for example,
> imagine multiple web servers on a machine where they didn't all use
> the same build. (Well, OK, I can imagine that they might run on
> different ports and be optimized differently enough to wind up with
> different kerb libs, but I would treat this as an unsupported corner
> case. Just make the name convention different enough that they don't
> damage each other.)
In the case of ccache format there is a real use for this: JGSS plus
whatever the OS's native implementation of Kerberos V is. This happens
a lot.
But for rcache I'm not sure that file format backwards compatibility
matters that much. Yes, if you're using one app built w/ MIT krb5 and
another built with Solaris krb5, both accepting contexts with the same
service principal, then you have a problem.
As with ccache format, a version number that is configurable through
krb5.conf can solve the problem... at the expense of bloat.
Nico
--
More information about the krbdev
mailing list