ksu can keep the user's ccache (the old one, not the newly created
one) locked while the new shell is running. It's a read lock, which
prevents other processes from modifying the file (e.g., adding newly
acquired tickets); they just hang until ksu exits.
The problem is really a bug down in the ccache code, where the wrong
data pointer is pulled out of a linked list, and used. But ksu is one
of the few programs that manipulates multiple ccaches; most other
programs wouldn't show the problem, and it only shows up with ksu if
some other program is also being run that has to fetch new tickets.
Any other programs maintaining multiple file ccaches may be affected
as well.
* cc_file.c (dereference): Fix test is list-walking loop.
ticket: new
target_version: 1.4.2
tags: pullup
git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@17243
dc483132-0cff-0310-8789-
dd5450dbe970
+2005-06-15 Ken Raeburn <raeburn@mit.edu>
+
+ * cc_file.c (dereference): Fix test is list-walking loop.
+
2005-04-13 Ken Raeburn <raeburn@mit.edu>
* cc_file.c (NEED_SOCKETS, NEED_LOWLEVEL_IO): Don't define.
kerr = k5_mutex_lock(&krb5int_cc_file_mutex);
if (kerr)
return kerr;
- for (fccsp = &fccs; *fccsp == NULL; fccsp = &(*fccsp)->next)
+ for (fccsp = &fccs; *fccsp != NULL; fccsp = &(*fccsp)->next)
if ((*fccsp)->data == data)
break;
assert(*fccsp != NULL);
+ assert((*fccsp)->data == data);
(*fccsp)->refcount--;
if ((*fccsp)->refcount == 0) {
struct fcc_set *temp;