Ticket History #2261: multiple threads requesting kerberos credentials when they do not exist will produce multiple kinit dialogs

Let's not worry about the technique to be used to detect multiple
instances of a dialog. I think I might even be able to
check within the dialog init procedure whether another of the same
dialog is active. We will just assume there is a way
to do it that works.

The first question is whether we want to make the restriction of the
kinit dialog being produced global
to an Application instance or to the Logon Session. For example, it
might be the case with multiple credential
caches that two different applications might want to obtain credentials
at the same time. It seems to me that
we might want to support that. Of course it might also be possible for
a single application instance to desire
separate credentials at the same time by using threads. Not that Eudora
is capable of this but if I was to use
Eudora to read accounts from mail servers in multiple realms this might
be a necessary capability. Although this
requirement would be harder to enforce but perhaps the restriction to
the display of the dialogs should be tied
to the credential cache name or even to the client principal name.

The second question is what should happen to the second process or
thread that wants to obtain credentials
when the dialog is already being displayed. Should this second thread
block or not? If yes, for how long?
If the operation is being called from within a thread acting as the pump
for a message queue implementing
blocking behavior can have very negative consequences. However,
returning immediately with an error
would imply that credentials were not available when they were in the
process of being obtained. In a
message queue thread it would not be wise to block for more than 50
msecs. In the none message queue
thread case it is probably safe to block indefinitely. What was done
for KfM?

- Jeff

KfM only allows one dialog at a time. If process A requests the dialog
and then process B requests the dialog while A's dialog is still up, B
will block. We provide a callback API for blocked processes so if B is
single-threaded and wishes to receive events while blocked it can
receive processor time.

Because locking in the CCAPI was never implemented, we actually have
worse problems than just multiple dialogs. If multiple processes read
and write to the CCAPI simultaneously (dialog or kinit or whatever),
they may end up leaving the cache collection in an inconsistent state.
To work around this, the KLL actually uses locking around all calls
which access the CCAPI, not just ones that pop the dialog. For
instance, KLAcquireInitialTickets(), which read the cache collection,
will place a read lock on the lock file. That lock is later promoted to
a write lock if it needs to write to the ccache collection.

In the dialog case, there is the client process and the
KerberosLoginServer which actually presents UI. All locking is done on
the client side, and the KerberosLoginServer never touches the lock
file. The reason for this is that the client usually already has a read
lock on the lock file when it pops up the dialog because it has just
checked to see if there are valid tickets. So the client places a write
lock on the file on behalf of the KerberosLoginServer just before
popping the dialog.

Unfortunately, this means that when the dialog is on-screen but not
being used, the client that popped the dialog has a write lock on the
file. As a result, other KLL callers can't get read locks. I'm hoping
to work around this for KfM 5.5 by implementing CCAPI locking, in which
case we could just use the lock file to control the number of dialogs on
the screen at a time.

Locking is currently implemented by calling flock() on the file
"KLLCCache.lock" in "/tmp/.KerberosLogin-<uid>/".

- Alexis

confirmation has been received that this problem is resolved.

"I have been using the preBeta 8 today and have been happy with it. It
has fixed the multiple get ticket windows problem."