| From: | raeburn@mit.edu |
| Subject: | CVS Commit |
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.
To generate a diff of this commit:
cvs diff -r5.156 -r5.157 krb5/src/lib/krb5/ccache/ChangeLog
cvs diff -r5.45 -r5.46 krb5/src/lib/krb5/ccache/cc_file.c
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.
To generate a diff of this commit:
cvs diff -r5.156 -r5.157 krb5/src/lib/krb5/ccache/ChangeLog
cvs diff -r5.45 -r5.46 krb5/src/lib/krb5/ccache/cc_file.c