Changing kerberos-interest at sun.com to kerberos-discuss at opensolaris.org ...
Nicolas Williams wrote: > 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. > I purposely specified "will allow", "support", and "helpful" in regards to sessions. As the applications still have an interface for designing specific forms of session. If the scope of the project is to define a system level or SPI then I believe that this warrants a separate case as it impacts many applications and not necessarily specific to Kerberos. >> 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. > Currently, gssd uses the principal to map to the local user. I believe that this is still useful and could be used in order to lookup a special CCAPI entry and to fall-back to file stores created by initial login. >>> 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? > If gssd goes away then the FMRI goes from being defined to that which is not :) >>> 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?) > Hmmm, locking down specific things like timing on process reaping might paint oneself in the corner in a requirements document. >> 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? > Not to paint myself in corner, x minutes. >> 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. > I certainly think that the session id SPI is a much needed project, however I don't think that it should be lumped into the CCAPI project. I can't decide on my own that CCAPI would block on a session id project, but I will certainly argue on both sides. Shawn. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/kerberos-discuss/attachments/20090120/d95906ec/attachment.html>
