svn rev #19328: branches/krb5-1-6/ src/lib/krb5/os/

[tlyu@MIT.EDU]

Commit By: tlyu
Log Message: 
ticket: 5437
version_fixed: 1.6.1

pull up r19154 from trunk

 r19154 at cathode-dark-space:  jaltman | 2007-02-12 09:54:28 -0500
 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  branches/krb5-1-6/
U   branches/krb5-1-6/src/lib/krb5/os/ccdefname.c