CCAPI needs to be one-per-system long-term

[Jeffrey Altman]

Sam Hartman wrote:
>
> IN the first cut of KFW 4.0 we're going to have a per-user ccapi process like we do today.
>
> However  I want to document some discussions with Jeff Altman on why
> we eventually want to strongly consider one ccapi cache server for the
> entire system.
>
> There are two issues.  The first is getting credentials from the login
> process into the ccapi  and the second is termination of the ccapi.
>
> THere is not a reliable way of getting some code you write executed in
> every new login session.  Today we're using login scripts.  They don't
> always get run.  For example they do not get run in sessions created
> by scheduled tasks.
Login scripts are also not executed when the desktop is unlocked which
prevents being able to automatically refresh credentials in response to
a manual Ctrl-Alt-Del or unlocking the screen saver.

Login scripts are also not run for remote connections that start
processes for a user but do not create a desktop.
>
> The other challenge is knowing when to terminate the ccapi server.
> Typically, if I understand this correctly, the ccapi server terminates
> when it receives a logout notification.  However there are classes of
> sessions that do not log out until all processes in the session
> terminate.  This creates a catch-22.
When "RUNAS" is used, a new logon session is created that shares the
current desktop.  The logon session is not terminated until all
processes within the session terminate.  For a normal interactive
desktop session the shell (explorer.exe) will close all processes in the
session.  For sessions created with RUNAS, there is no shell to manage
the child processes.  Instead, the command being executed by RUNAS is
started directly.  If it in turn causes another process such as the
ccapi server to start and does not shut it down, then the logon session
will never terminate.   I guess we could add code to the ccapi server
process to periodically enumerate all processes and determine if it is
the last one in the current session and if so have it terminate. 
Although, that may require privileges that the process does not in fact
possess.

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kfwdev/attachments/20070604/9c261566/attachment.bin