Re: GGF's extensions to GSS in Public Comment

This statement captures what I was missing:

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

I think you are right, if the applicaiton understands that
gss_store_cred() may impact the operating environment and makes sure
to call it at the right point, this should solve the issue of setting
up a child's environment.

However, it doesn't cover the case of an application spawning a child
through an execle() right?

Von



Nicolas Williams writes (22:14 April 7, 2004):
 > 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]