Re: krb_server_keyfile setting doesn't work on Windows

Magnus Hagander wrote:
> On Thu, Dec 31, 2009 at 00:57, Magnus Hagander <magnus@hagander.net> wrote:
>> 2009/12/31 Hiroshi Inoue <inoue@tpf.co.jp>:
>>> Magnus Hagander wrote:
>>>> 2009/12/30 Hiroshi Inoue <inoue@tpf.co.jp>:
>>>>> Hi,
>>>>>
>>>>> As far as I tested, the krb_server_keyfile setting
>>>>> in postgres.conf doesn't work on Windows.
>>>>>
>>>>> Because gssapi32.dll(krb5_32.dll) seems to call
>>>>> getenv("KRB5_KTNAME") in msvcr71, postgres.exe
>>>>> should call putenv("KRB5_KTNAME=...") in msvcr71.
>>>>> The attached patch fixes the problem in my test
>>>>> case.
>>>> Isn't the main backend linked with msvcr71.dll anyway?
>>> What main backend directly links is msvcr80 or msvcr90
>>> according to the msvc build environment.
>> Arrgh. My bad, I thought msvcr71 was vs2005. Now that you put it like
>> this, I know it's vs2003.
>>
>>
>>>> Then the
>>>> regular putenv should put it in th eenv of  msvcr71.dll, and the stuff
>>>> that's wrapped through src/port/win32env.c will put it in the regular
>>>> msvcr file.
>>>>
>>>> I wonder if you're possibly being hit with the bug I patched the other
>>>> day, but didn't backpatch.
>>>> (http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=f8bcd7220b1166f7c037ceaf0a53958cbc6a7630).
>>>>
>>>> Can you see if that fix solves your problem as well? (Either directly
>>>> or by testing HEAD)
>>> I'm testing using the current cvs.
>>>
>>>> If not, the fix should still go in win32env.c, not directly in auth.c
>>> I don't object to it. Possibly we would have to add msvcr80 or
>>>  msvcr90 as well in the future.
>> To be safe, yes, we should have that. Do you want to work on such a
>> complete solution, or should I look at it?
> 
> Mail to you seem not to be properly delivered atm :-( Hopefully you
> can read this through the list.

Sorry for the delay - I've been on new year holiday in Japan.

> I've applied a patch that should fix this problem, by always updating
> *all* available msvcrt libraries. Please  check that it solves your
> problem as well.

I checked the behavior using the current cvs and it works well.
Thanks.

regards,
Hiroshi Inoue