Nicolas Williams wrote: > On Thu, Jan 15, 2009 at 08:42:15AM -0800, Wyllys Ingersoll wrote: > >> 1. Introduction >> >> Project will create a new credential cache type that will allow a per >> session Kerberos credential cache. The CCAPI cache type will not be >> the default credential cache type for normal initial authentication, >> it will remain "FILE". >> >> Per session ccaches is highly desirable for a number of reasons, but >> for this particular project it is required that credentials used for >> long running proccesses not interfere/overwrite credentials that are >> created from normal operations such as initial authentication or >> delegation. >> > > Given the way gssd works (even if revamped to be per-user gssd > instances), to me per-session ccache means adding a kernel-land > mechanism for associating user processes with "sessions." > > 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.
> One possibility is that gssd (or each per-user gssd) will try all of the > per-session CCAPI daemons, as opposed to trying to find the CCAPI daemon > associated with the process that triggered the upcall to gssd. > > Either way, there's something missing here. > 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. >> 3. Daemon >> >> New per user daemon is proposed, ccd (credential cache daemon). >> ccd(1M) >> contains various credential cache stores for the user. Particular >> ccache stores in the daemon are referenced by the tuple >> (uid, session id). The uid and session-id are ascii string >> characters. >> session id can be configurable through libraries and environment >> variable. >> > > 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 :) > 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". Additional advice given is that the ccache server should exit after inactivity, therefore store the ccache encrypted on disk. 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 :) >> 5. IPC >> >> Preferred form of IPC is doors, even though MIT implementation in >> Unix is domain sockets. With doors we can perform credentialling >> with >> native functions, e.g. door_ucred(3C). >> >> An attempt will be made to make the IPC code as portable as possible. >> > > Are people using MIT krb5 CCAPI on Solaris today? If so, that's an > argument for keeping the Unix domain socket IPC. Otherwise I'd argue > that you need to have only doors IPC. > No, just Mac and Windows users. Shawn. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090120/51d7e354/attachment.html>
