r19154@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.
ticket: 5437
version_fixed: 1.6.1
git-svn-id: svn://anonsvn.mit.edu/krb5/branches/krb5-1-6@19328
dc483132-0cff-0310-8789-
dd5450dbe970