Horton

Thread

Commits

  1. Use SOCK_ERRNO[_SET] in fe-secure-gssapi.c.

  1. psql client does not handle WSAEWOULDBLOCK on Windows

    Ning <ning94803@gmail.com> — 2024-07-30T08:47:35Z

    *Description:*The connection fails with a non-blocking socket error when
using psql on
Windows to connect to a PostgreSQL server with GSSAPI enabled. The error is
because the socket error code is obtained by WSAGetLastError() instead of
errno. This causes the value of errno to be incorrect when handling a
non-blocking socket error.


*Steps to Reproduce:*1. Compile PostgreSQL client (psql) on Windows.
a. Make sure MIT Kerberos is installed. I use the latest version MIT
Kerberos
Version 4.1.
b. Make sure GSSAPI is enabled
2. Attempt to connect to a PostgreSQL server using psql.
a. Set up the Kerberos server and configure the PostgreSQL server by
referring
to https://github.com/50wu/kerberos-docker/blob/main/POSTGRES.README.md
b. change the entry to hostgssenc on PostgreSQL server pg_hba.conf and
restart
hostgssenc    all    all    0.0.0.0/0    gss    include_realm=0
krb_realm=GPDB.KRB
c. Use the following command to connect to the database server
psql -h <hostname> -U "postgres/krb5-service-example-com.example.com" -d
postgres
3. The connection fails with a non-blocking socket error. The error is
something like:
psql: error: connection to server at "xxx", port 5432 failed:

*Environment*:
PostgreSQL version: 16.3
Operating System: Windows 11


*Fix Steps:*In the gss_read function of
src/interfaces/libpq/fe-secure-gssapi.c, change the
check of the error code to use the SOCK_ERRNO to make sure that EAGAIN,
EWOULDBLOCK and EINTR can be properly handled on Windows and other
platforms.

The patch file is attached to this email, please review and consider
merging it to
the main code library.

Thanks,
Ning Wu

  2. Re: psql client does not handle WSAEWOULDBLOCK on Windows

    Umar Hayat <postgresql.wizard@gmail.com> — 2024-08-05T15:17:38Z

    I have not reproduce your test scenario, looking at code please see following comments:

If you check the function definition of pqsecure_raw_read() it actually do set errno like bellow

SOCK_ERRNO_SET(result_errno);
where result_errno = SOCK_ERRNO

Means anybody using those function pqsecure_raw_read/write, does not need to take care of portable ERRNO.

Regards
Umar Hayat

The new status of this patch is: Waiting on Author

  3. Re: psql client does not handle WSAEWOULDBLOCK on Windows

    Ning <ning94803@gmail.com> — 2024-08-06T08:01:42Z

    Hi Umar,

In the function of gss_read() if print the value of errno and SOCK_ERRNO
separately, I found the values are different:
 *ret = pqsecure_raw_read(conn, recv_buffer, length);
if (*ret < 0)
{
printf("errno: %d\n", errno);
printf("result_errno: %d\n", SOCK_ERRNO);
...

errno: 0
result_errno: 10035

Also refer to the
https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsagetlasterror
,
It shows that the Windows Sockets function does not set errno, but uses
WSAGetLastError to report errors. And refer to the
https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-recv
,
If the function fails, it should call the WSAGetLastError to get the
expansion
error message. This further shows that the socket operation error will not
be
reported through the errno.

So changing the error code check to use the SOCK_ERRNO instead of errno can
be
properly handled on both Windows and other platforms.

To reproduce the issue, I used the following version of Postgres and MIT
Kerberos:
PostgreSQL version: 16.3
MIT Kerberos Version 4.1
Operating System: Windows 11
Visual Studio 2022


On Tue, Jul 30, 2024 at 4:47 PM Ning <ning94803@gmail.com> wrote:

>
> *Description:*The connection fails with a non-blocking socket error when
> using psql on
> Windows to connect to a PostgreSQL server with GSSAPI enabled. The error is
> because the socket error code is obtained by WSAGetLastError() instead of
> errno. This causes the value of errno to be incorrect when handling a
> non-blocking socket error.
>
>
> *Steps to Reproduce:*1. Compile PostgreSQL client (psql) on Windows.
> a. Make sure MIT Kerberos is installed. I use the latest version MIT
> Kerberos
> Version 4.1.
> b. Make sure GSSAPI is enabled
> 2. Attempt to connect to a PostgreSQL server using psql.
> a. Set up the Kerberos server and configure the PostgreSQL server by
> referring
> to https://github.com/50wu/kerberos-docker/blob/main/POSTGRES.README.md
> b. change the entry to hostgssenc on PostgreSQL server pg_hba.conf and
> restart
> hostgssenc    all    all    0.0.0.0/0    gss    include_realm=0
> krb_realm=GPDB.KRB
> c. Use the following command to connect to the database server
> psql -h <hostname> -U "postgres/krb5-service-example-com.example.com" -d
> postgres
> 3. The connection fails with a non-blocking socket error. The error is
> something like:
> psql: error: connection to server at "xxx", port 5432 failed:
>
> *Environment*:
> PostgreSQL version: 16.3
> Operating System: Windows 11
>
>
> *Fix Steps:*In the gss_read function of
> src/interfaces/libpq/fe-secure-gssapi.c, change the
> check of the error code to use the SOCK_ERRNO to make sure that EAGAIN,
> EWOULDBLOCK and EINTR can be properly handled on Windows and other
> platforms.
>
> The patch file is attached to this email, please review and consider
> merging it to
> the main code library.
>
> Thanks,
> Ning Wu
>

  4. Re: psql client does not handle WSAEWOULDBLOCK on Windows

    Michael Paquier <michael@paquier.xyz> — 2024-12-10T06:41:02Z

    On Tue, Aug 06, 2024 at 04:01:42PM +0800, Ning wrote:
> In the function of gss_read() if print the value of errno and SOCK_ERRNO
> separately, I found the values are different:
>  *ret = pqsecure_raw_read(conn, recv_buffer, length);
> if (*ret < 0)
> {
> printf("errno: %d\n", errno);
> printf("result_errno: %d\n", SOCK_ERRNO);
> ...

     *ret = pqsecure_raw_read(conn, recv_buffer, length);
     if (*ret < 0)
     {
-        if (errno == EAGAIN || errno == EWOULDBLOCK || errno == EINTR)
+        if (SOCK_ERRNO == EAGAIN || SOCK_ERRNO == EWOULDBLOCK || SOCK_ERRNO == EINTR)

This is going to require some platform-specific check that I don't
have with me, though I am ready to accept that what you are telling
here is true and that we should apply this macro.  Could somebody
check that a bit more in depth?  Andrew D. perhaps?

One thing that I don't understand is why does this only apply after
the first call of pqsecure_raw_read() in gss_read()?  There is a
second call of pqsecure_raw_read() you are not covering but it would
surely need the same treatment, no?

Also, what about pqsecure_raw_write() in pqsecure_open_gss()?
Shouldn't the same check apply?
--
Michael

  5. Re: psql client does not handle WSAEWOULDBLOCK on Windows

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-09-02T15:51:41Z

    Michael Paquier <michael@paquier.xyz> writes:
> This is going to require some platform-specific check that I don't
> have with me, though I am ready to accept that what you are telling
> here is true and that we should apply this macro.  Could somebody
> check that a bit more in depth?  Andrew D. perhaps?

> One thing that I don't understand is why does this only apply after
> the first call of pqsecure_raw_read() in gss_read()?  There is a
> second call of pqsecure_raw_read() you are not covering but it would
> surely need the same treatment, no?

> Also, what about pqsecure_raw_write() in pqsecure_open_gss()?
> Shouldn't the same check apply?

Yeah, I think we pretty much need to use SOCK_ERRNO, SOCK_ERRNO_SET,
and SOCK_STRERROR (if relevant) throughout fe-secure-gssapi.c.
Directly using errno is correct for syscalls related to the file
system, but I think everything in this file is dealing with
socket-related errors.  Certainly the underlying pqsecure_raw_read
and pqsecure_raw_write layer expects those macros to be used.

Like you, I'm not really in a position to test this on Windows ...

			regards, tom lane

  6. Re: psql client does not handle WSAEWOULDBLOCK on Windows

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-10-05T19:14:44Z

    I wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> Also, what about pqsecure_raw_write() in pqsecure_open_gss()?
>> Shouldn't the same check apply?

> Yeah, I think we pretty much need to use SOCK_ERRNO, SOCK_ERRNO_SET,
> and SOCK_STRERROR (if relevant) throughout fe-secure-gssapi.c.

Since nothing seems to be happening here, I took another look and
decided that the required changes are really pretty straightforward.
fe-secure-gssapi.c doesn't contain any strerror calls, and its
touches of errno all appear to relate to socket errors, so we can
just change them all.  As attached.

> Like you, I'm not really in a position to test this on Windows ...

I'm still not, but it's straightforward enough that I'm willing to
push on my own authority.  I'll just put this up for long enough
to make sure that the cfbot is happy with it --- though I think
it's not building with GSSAPI on Windows, so that may prove little.

			regards, tom lane