From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Unportable(?) use of setenv() in secure_open_gssapi() |
Date: | 2019-12-17 01:44:27 |
Message-ID: | 9165.1576547067@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> It's been project policy since 2001 to avoid setenv(), and I notice
>> that src/port/win32env.c lacks support for setenv(), making it
>> pretty doubtful that the call has the semantics one would wish
>> on Windows.
> Yeah, that doesn't seem good, though you'd have to be building with MIT
> Kerberos for Windows to end up with GSSAPI on a Windows build in the
> first place (much more common on Windows is to build with Microsoft SSPI
> support instead). Still, it looks like someone went to the trouble of
> setting that up on a buildfarm animal- looks like hamerkop has it.
It looks like it'd only matter if Kerberos were using a different CRT
version than PG proper, which is probably even less likely. Still,
that could happen.
> So, auth.c already does the song-and-dance for putenv for this exact
> variable, but it happens too late if you want to use GSSAPI for an
> encrypted connection. Looking at this now, it seems like we should
> really just move up where that's happening instead of having it done
> once in be-secure-gssapi.c and then again in auth.c. Maybe we could do
> it in BackendInitialize..?
Hm, yeah, and it's also pretty darn inconsistent that one of them does
overwrite = 1 while the other emulates overwrite = 0. I'd be for
unifying that code. It'd also lead to a more safely back-patchable
fix than the other solution.
Going forward, adding support for setenv() wouldn't be an unreasonable
thing to do, I think. It's certainly something that people find
attractive to use, and the portability issues we had with it back at
the turn of the century should be pretty much gone. I do note that my
old dinosaur gaur, which is the last surviving buildfarm member without
unsetenv(), lacks setenv() as well --- but I'd be willing to add support
for that as a src/port module. We'd also have to fix win32env.c, but
that's not much new code either.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-12-17 02:18:23 | Re: reducing memory usage by using "proxy" memory contexts? |
Previous Message | Stephen Frost | 2019-12-17 00:46:32 | Re: Unportable(?) use of setenv() in secure_open_gssapi() |