Re: GGF's extensions to GSS in Public Comment

On Thu, Apr 08, 2004 at 12:17:14PM -0500, Von Welch wrote:
> 
> 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?

Depends.

Before I go into this I should point out that even before the advent of
either of our proposals execle()/execve() were a problem on platforms
where the current credential store is determined by environment
variables.  I.e., this is not a new problem, it's not new with my
proposal and it's not solved by yours either.

Anyways, for platforms where GSS_Set_cred_store()/GSS_Store_cred() deal
in environment variables, then yes, the application will have to be
careful to preserve parts of its environment when doing any execle() or
execve() call.

And for other platforms, where GSS_Set_cred_store()/GSS_Store_cred()
deal in per-user credential stores, or per-session credential stores
where a system call informs the kernel about a process' (or thread's)
current credential store, no, there's no execle()/execve() gotcha.

Just look at OpenSSH code, for example, and you'll see that it has to be
careful about environment variables even without throwing in the
GSS-API.

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]