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/kerberos-discuss/attachments/20090202/6c8a34c2/attachment.html>