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