Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)
Subject: krb5_verify_init_creds behaves badly with a ticket cache
X-RT-Original-Encoding: iso-8859-1
Content-Length: 1948

If the ticket cache argument to krb5_verify_init_creds is non-NULL and
points to an existing file cache (if it points to a memory cache or to a
NULL pointer, everything still works), krb5_verify_init_creds fails with
an internal error because it tries to write to a ticket cache opened
read-only.

To see why, observe that krb5_verify_init_creds calls
krb5_cc_copy_creds_except to do the work of copying the credentials into
the cache.  The first thing that function does is call krb5_cc_set_flags
on both ticket caches to turn off OPENCLOSE mode.  However, in the file
cache implementation, as soon as OPENCLOSE mode is turned off, the file
(which is always at that point closed) is opened read-only.  When
credentials are stored in the target cache, a write is done without
trying to reopen the cache read/write, since it's already open, and the
operation then fails with an OS error.

The quick fix is to not call krb5_cc_set_flags on the target cache and
leave it in OPENCLOSE mode.  This shouldn't be a noticable performance
issue; for one, krb5_verify_init_creds is not a performance-critical
operation since it's normally done only once in the lifetime of a ticket
cache, and for another, there are generally only two tickets in the
credential cache it's copying.

However, I think there's a deeper bug here.  Turning off OPENCLOSE mode
shouldn't make a ticket cache read-only.  Fixing that, however, may be
problematic; the cleanest fix code-wise that I can see would be to store
a flag in the ticket cache structure saying what mode the cache was
opened in and then reopening it as needed for a particular operation. 
That may not be too bad, since it looks like the structure is not
exposed in the API, but it requires changing a lot of code.  My guess is
that always reopening the ticket cache read/write won't be acceptable
since it disallows read-only ticket caches when OPENCLOSE mode is turned
off, something that doesn't feel clean.