Re: GGF's extensions to GSS in Public Comment
Von Welch <[email protected]> Wed, 7 Apr 2004 18:03:24 -0500
| Newsgroups | gmane.ietf.cat |
|---|---|
| Message-ID | <[email protected]> |
Nico, This text from your draft describing set_current_cred_store() gets at the problem we were trying to solve by including env variables in the output of gss_export_cred(): > Calls to this function MAY have platform-specific side effects (e.g., > setting environment variables, setting a process' "pag," etc...), but > an implementation of it MUST NOT change the user context of the > application, a restriction applicable only on multi-user platforms. For credential stores that are meaningful to the kernel, the application doesn't in general have to be aware of them since the kernel will generally make sure the process doesn't accidentially meddle with them. (E.g. if a process changes its PAG it typically knows what it is doing.) But for GSS mechanisms that don't have kernel support for their creentials stores and use environment variables, this isn't the case. A process might decide to clean up its environment for a number of reasons and accidentially effect the GSS mechanism's current credential store or fail to pass the meaningful env variable to a child process as in SSHD. This is what led us to have a mechanism that allowed the GSS mechanism to tell the calling application that a particular env variable was meaningful to it so that a well behaved application could treat that variable appropriately. You are right in that our use of environment variables was focused on a couple of specific mechanisms (GSI & Krb5) in which we were interested. I agree the approach does not generalize well to mechanisms that use other methods besides env variables. However I still believe it solves a problem for those mechanisms that I don't undertstand how your approach solves yet. (BTW, is the intent that gss_set_current_cred_store() can create a new credential store, presumably if cred_store_handle has some special value?) Von -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to [email protected]