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