[HACKERS] SSPI vs MingW
I just came across yet another place where MingW isn't compatible with the windows api. Specifically, their libsecur32.a file lacks at least one function that is needed to implement SSPI authentication. The way I can see it, there are three ways to solve it: 1) Simply state that SSPI authentication in the backend cannot be built with mingw, and require msvc build for it (the msvc api follows the windows api, which is hardly surprising). We could add an autoconf test for it that'd pick up an updated libsecur32.a file if/when mingw release an update. 2) Ship our own secur32.def file, and automatically build an import library for it that we can link against. Because the function is present in the DLL file, this works fine. 3) Dynamically load the function at runtime, thus completely ignoring the need for an import library for it. What do people feel about these options? I'm annoyed enough with mingw right now (after having tracked this stupid thing down) that I'm probably not thinking clearly enough to say something myself :) Oh, and feel free to tell me which option(s) I missed completely.. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] SSPI vs MingW
Magnus Hagander wrote: I just came across yet another place where MingW isn't compatible with the windows api. Specifically, their libsecur32.a file lacks at least one function that is needed to implement SSPI authentication. The way I can see it, there are three ways to solve it: Ugh. 1) Simply state that SSPI authentication in the backend cannot be built with mingw, and require msvc build for it (the msvc api follows the windows api, which is hardly surprising). We could add an autoconf test for it that'd pick up an updated libsecur32.a file if/when mingw release an update. I prefer this option, if only because I have little interest in supporting mingw any longer than necessarily, but I realise others may want to use it so... 2) Ship our own secur32.def file, and automatically build an import library for it that we can link against. Because the function is present in the DLL file, this works fine. Yuck. 3) Dynamically load the function at runtime, thus completely ignoring the need for an import library for it. That gets my vote. It's relatively clean and non-kludgy. Regards, Dave ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SSPI vs MingW
On Mon, Jul 23, 2007 at 11:06:59AM +0100, Dave Page wrote:
Magnus Hagander wrote:
I just came across yet another place where MingW isn't compatible with the
windows api. Specifically, their libsecur32.a file lacks at least one
function that is needed to implement SSPI authentication. The way I can see
it, there are three ways to solve it:
Ugh.
Indeed.
1) Simply state that SSPI authentication in the backend cannot be built
with mingw, and require msvc build for it (the msvc api follows the windows
api, which is hardly surprising). We could add an autoconf test for it
that'd pick up an updated libsecur32.a file if/when mingw release an
update.
I prefer this option, if only because I have little interest in
supporting mingw any longer than necessarily, but I realise others may
want to use it so...
Heh, well, I don't see that one going away...
2) Ship our own secur32.def file, and automatically build an import library
for it that we can link against. Because the function is present in the DLL
file, this works fine.
Yuck.
3) Dynamically load the function at runtime, thus completely ignoring the
need for an import library for it.
That gets my vote. It's relatively clean and non-kludgy.
Ok, jus so people knowing what amount of code we're talking about, here's a
patch that does this. Awaiting further comments :-)
//Magnus
Index: src/backend/libpq/auth.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/libpq/auth.c,v
retrieving revision 1.154
diff -c -r1.154 auth.c
*** src/backend/libpq/auth.c23 Jul 2007 10:16:53 - 1.154
--- src/backend/libpq/auth.c23 Jul 2007 12:52:01 -
***
*** 567,572
--- 567,575
errdetail(%s (%x), sysmsg, r)));
}
+ typedef SECURITY_STATUS
+ (SEC_ENTRY * QUERY_SECURITY_CONTEXT_TOKEN_FN)(
+ PCtxtHandle, void SEC_FAR * SEC_FAR *);
static int
pg_SSPI_recvauth(Port *port)
***
*** 591,596
--- 594,601
DWORD accountnamesize = sizeof(accountname);
DWORD domainnamesize = sizeof(domainname);
SID_NAME_USEaccountnameuse;
+ HMODULE secur32;
+ QUERY_SECURITY_CONTEXT_TOKEN_FN _QuerySecurityContextToken;
/*
***
*** 728,737
* pg username that was specified for the connection.
*/
! r = QuerySecurityContextToken(sspictx, token);
if (r != SEC_E_OK)
pg_SSPI_error(ERROR,
gettext_noop(could not get security token from
context), r);
/*
* No longer need the security context, everything from here on uses the
--- 733,763
* pg username that was specified for the connection.
*/
! secur32 = LoadLibrary(SECUR32.DLL);
! if (secur32 == NULL)
! ereport(ERROR,
! (errmsg_internal(could not load secur32.dll: %d,
! (int)GetLastError(;
!
! _QuerySecurityContextToken = (QUERY_SECURITY_CONTEXT_TOKEN_FN)
! GetProcAddress(secur32, QuerySecurityContextToken);
! if (_QuerySecurityContextToken == NULL)
! {
! FreeLibrary(secur32);
! ereport(ERROR,
! (errmsg_internal(could not locate
QuerySecurityContextToken in secur32.dll: %d,
! (int)GetLastError(;
! }
!
! r = (_QuerySecurityContextToken)(sspictx, token);
if (r != SEC_E_OK)
+ {
+ FreeLibrary(secur32);
pg_SSPI_error(ERROR,
gettext_noop(could not get security token from
context), r);
+ }
+
+ FreeLibrary(secur32);
/*
* No longer need the security context, everything from here on uses the
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] SSPI vs MingW
Dave Page wrote: Magnus Hagander wrote: I just came across yet another place where MingW isn't compatible with the windows api. Specifically, their libsecur32.a file lacks at least one function that is needed to implement SSPI authentication. The way I can see it, there are three ways to solve it: Ugh. agreed. 1) Simply state that SSPI authentication in the backend cannot be built with mingw, and require msvc build for it (the msvc api follows the windows api, which is hardly surprising). We could add an autoconf test for it that'd pick up an updated libsecur32.a file if/when mingw release an update. I prefer this option, if only because I have little interest in supporting mingw any longer than necessarily, but I realise others may want to use it so... I don't think it's going away any time soon. For example, it's the only platform I've been able to make work on my Vista box, and nobody has told me how to get around the problems, even though apparently some have managed to make MSVC work on Vista. This is the least good option IMNSHO. 2) Ship our own secur32.def file, and automatically build an import library for it that we can link against. Because the function is present in the DLL file, this works fine. Yuck. 3) Dynamically load the function at runtime, thus completely ignoring the need for an import library for it. That gets my vote. It's relatively clean and non-kludgy. Yes, I can live with this one too, although I don't think option 2 is so bad either. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] SSPI vs MingW
Dave Page [EMAIL PROTECTED] writes: Magnus Hagander wrote: 1) Simply state that SSPI authentication in the backend cannot be built with mingw, and require msvc build for it (the msvc api follows the windows api, which is hardly surprising). We could add an autoconf test for it that'd pick up an updated libsecur32.a file if/when mingw release an update. I prefer this option, +1. I grow weary of working around so many Windows-related bugs/omissions. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
