Re: Unportable(?) use of setenv() in secure_open_gssapi()

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

In response to

Browse pgsql-hackers by date

  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()