On Tue, Jan 20, 2009 at 01:28:22AM -0700, Shawn M Emery wrote: > Nicolas Williams wrote: > >If such a mechanism is missing then this case seems incomplete. > > > I purposely left the session naming mechanism out of the one-pager, as I > believe something more systemic needs to thought out and deserves it's > own case and transcends anything in CCAPI's scope.
Then as long as this case retains the words "per-session" it will be incomplete. Either remove those words, add the missing facility, or block on a future case that should provide it. > My primary reasoning of having the CCAPI is the ability to have multiple > default credentials for purpose of separating initial login credentials > and those required for long running and delayed execution processes. To > this purpose all that would be required is two forms of cache naming > those of delayed execution and those of initial login. To me this is an > implementation detail. Without a kernel-side hook these credentials will not be available for secure NFS on a per-session basis. Therefore this is insufficient and incomplete. > >Where are the door handles for CCAPI daemons fattach()ed? > > > >How are these daemons started? > > > >For example, gssd using doors should be started by svc.startd, not > >inetd. So there's at least one architectural change that probably needs > >to be described (but maybe not -- is the restarter for a service an > >architectural detail?). > > Yes, as it affects the FMRI, but I haven't done away with gssd yet :) Why should the FMRI change? > >How are the CCAPI daemons started? Are they started by pam_krb5(5)? > >By kinit(1)? By an IPC call from either pam_krb5(5) or kinit(1) to a > >master CCAPI daemon started by SMF? > > > >And how are these daemons reaped? For login sessions [where pam_krb5 is > >involved[ I'd expect that pam_krb5:pam_sm_close_session() takes care of > >it. But if new CCAPI daemon processes can be started by kinit, then how > >are they destroyed? > > To me these are all implementation details that I purposely did not > cover in the requirements details. But in any case, here are > implementation details, for the curious: > > http://k5wiki.kerberos.org/wiki/Projects/CCAPI_for_UNIX > > under "Spawning new server and connecting". That has implementation details, but strongly implies a UI and/or API. Those missing interfaces need to be described. (Surely the protocol described in the linked page is not intended for _users_ to execute through netcat or some such, right?) > Additional advice given is that the ccache server should exit after > inactivity, therefore store the ccache encrypted on disk. How will the daemon know when no long-running processes require it any longer? > I think any further implementation details can be taken off list. I'm > just trying to get requirements approval at this point, as I certainly > don't want to paint myself in the corner on an implementation detail > that I discover later on is not the most efficient/reasonable design :) I believe this case is incomplete as it stands. Were I an ARC member I'd ask you to address these issues and update the materials, else derail. I hope an ARC member does as much. Nico --
