svn rev #19154: trunk/src/lib/krb5/os/

jaltman@MIT.EDU jaltman at MIT.EDU
Mon Feb 12 09:54:29 EST 2007


Commit By: jaltman
Log Message: 
ticket: new
subject: hack to permit GetEnvironmentVariable usage without requiring getenv() conversion
tags: pullup

	Windows has a major flaw when it comes to the use of getenv/putenv.
	getenv/putenv do not modify the actual environment of the process.
	Instead, they modify a copy of the environment block at the time the
	C Runtime Library was initialized for the current module.  In other 
	words, the C Runtime Library environment block for the executable
	is not the same as the C Runtime Library environment block for the
	krb5_32.dll library, etc.

	This results in problems when a process wants to set the default
	ccache name outside the krb5_context.  The krb5_context default ccname
	disappears when the context is destroyed.  gss_acquire_cred() suffers
	from the creation and destruction of krb5_contexts and therefore the
	krb5_context default ccname cannot be used to set a default ccname.
	Instead, the process environment must be used.

	In order to modify the process environment, SetEnvironmentVariable()
	must be used.  However, this does not result in the C Runtime Library
	environment blocks being updated.  putenv() does not see the definition
	of "KRB5CCNAME".  

	This patch modifies get_os_ccname() for Windows to check 
	GetEnvironmentVariable() before checking the registry.  This hack will
	work as long as there is no "KRB5CCNAME" variable in the C Runtime 
	Library environment block.  

	The long term solution is to replace all calls to getenv and putenv
	with GetEnvironmentVariable/SetEnvironmentVariable for Windows.





Changed Files:
U   trunk/src/lib/krb5/os/ccdefname.c



More information about the cvs-krb5 mailing list