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]