Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) From: tlyu@mit.edu Subject: SVN Commit RT-Send-CC: X-RT-Original-Encoding: iso-8859-1 Content-Length: 1808 pull up r19154 from trunk 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. Commit By: tlyu Revision: 19328 Changed Files: _U branches/krb5-1-6/ U branches/krb5-1-6/src/lib/krb5/os/ccdefname.c