Re: Unportable(?) use of setenv() in secure_open_gssapi() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Unportable(?) use of setenv() in secure_open_gssapi()
Date
Msg-id 9165.1576547067@sss.pgh.pa.us
Whole thread Raw
In response to Re: Unportable(?) use of setenv() in secure_open_gssapi()  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Unportable(?) use of setenv() in secure_open_gssapi()
Next
From: Andres Freund
Date:
Subject: Re: reducing memory usage by using "proxy" memory contexts?