[kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009]

[Shawn M Emery]

Response to questions in-line:

Gary Winiger wrote:
>> 4. Technical Description
>>     
>
> 	I must say having read through this case, it is non-obvious to
> 	me what is being proposed and how it solves the problem of delayed
>   

Besides the internal and external presentations I have given on the 
overall project, perhaps I should file an umbrella PSARC case that 
outlines the three projects together and how they interact?

> 	execution.  Perhaps I missed it, what's the relationship between gssd and 		ccd?
>   

For Kerberos, gssd is a client of ccd, just like any other application 
obtaining service tickets.

> Is there a persistent (i.e., across reboot) credential cache such that delayed execution jobs will run on a freshly booted system?
>   

No, this is part of the future project of getting initial credentials 
(gic) through keytab PAM module project.

> 	To me the works "per session" mean beween the time of authentication to the exit of that "process group".  Is there a different definition for this case?

No, this case is specific to delayed execution, which uses its own 
session identifier for processes such as cron/at or anything else that 
uses the gic through keytab module.  This would have a fall-back 
mechanism to FILE ccaches, if CCAPI failed.

> How does this all relate to a per-user ccd?
>   

See above.

> On a SRSS server with 100s of users, will there be 100s of ccd/gssd-s?

As described in the one-pager, the plan is not to make the CCAPI the 
default credential cache as to minimize impact in environments such as this.

> When and how is the per-user cache "destroyed"?
>   

kdestroy(1) or after x minutes of inactivity, afterall initialization of 
credentials is dynamic with cron, as the PAM module would perform a gic 
w/keytab during cron's setcred pass.  This has an advantage of not 
having to change applications.  With the new module, you could also gic 
keytab at intervals by creating a simple application.

Shawn.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090202/6c8a34c2/attachment.html>