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. 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. > 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?). 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? > 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. Nico --
