Re: GGF's extensions to GSS in Public Comment

On Wed, Apr 07, 2004 at 06:03:24PM -0500, Von Welch wrote:
> 
> 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.

Yes.  See below.

> 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.

The calls to [GSS_Set_cred_store()/]GSS_Store_cred() need to happen
where your application today would go about setting up the environment
(and here I don't mean just variables) of the process it will spawn or
exec.

> 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.

But you failed to abstract the matter sufficiently.  See above.

> 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.

I said (or should have, if I said "mechanisms" instead)
"implementations."  Nothing in rfc1964 (the Kerberos V mechanism) says
[or ought say] anything whatsoever about environment variables.

The implementation(s) of the Kerberos V mechanism that you are used to
happen to use environment variables, but I dare say that this is mostly
a result of those implementations being alien to the operating systems
on which they are used.  Native implementations (e.g., Microsoft's)
don't have anything at all to do with environment variables.

> However I still believe it solves a problem for those mechanisms that
> I don't undertstand how your approach solves yet.

I make another attempt to explain it below.  To me it's clear as it can
be.

> (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?)

 - The intent of GSS_Get_cred_store() is to get a handle for the current
   credential store.

 - The purpose of GSS_Set_cred_store() is to set the current cred store
   to the given handle OR, if the NULL handle is given, to a *new*
   store.

 - The intent of GSS_Store_cred() is to store the given credential into
   the current credential store.

I consider GSS_Get_cred_store()/GSS_Set_cred_store() to be optional
because the one factor that cannot be easily abstracted is user context
switching (e.g., setuid(2)), yet user context switching generally does
[must!] change the current credential store (switching user context
means giving up access to some objects and gaining access to others).

So you see, on platforms with one credential store per-user, as opposed
to per-session, there is no need at all for GSS_Get/Set_cred_store()...
-- user context switching suffices, and all multi-user platforms have a
way to do that already!

If this is still not clear maybe we should have a conference call, or
perhaps we can discuss this in person at the next IETF meeting, or
perhaps at the next KRB WG interim meeting, if one is held and you and I
manage to be able to attend it.

Cheers,

Nico
-- 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]