rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/interfaces/libpq/fe-connect.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

7394 lines
187 KiB
C
Raw Normal View History

Remove unintended file change.
2005-08-09 07:14:26 +02:00
/*-------------------------------------------------------------------------
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*
Change my-function-name-- to my_function_name, and optimizer renames.
1999-02-14 00:22:53 +01:00
* fe-connect.c
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
* functions related to setting up a connection to the backend
*
Update copyright for 2022 Backpatch-through: 10
2022-01-08 01:04:57 +01:00
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
Add: * Portions Copyright (c) 1996-2000, PostgreSQL, Inc to all files copyright Regents of Berkeley. Man, that's a lot of files.
2000-01-26 06:58:53 +01:00
* Portions Copyright (c) 1994, Regents of the University of California
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*
*
* IDENTIFICATION
Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
* src/interfaces/libpq/fe-connect.c
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*
*-------------------------------------------------------------------------
*/
Restructure the key include files per recent pghackers discussion: there are now separate files "postgres.h" and "postgres_fe.h", which are meant to be the primary include files for backend .c files and frontend .c files respectively. By default, only include files meant for frontend use are installed into the installation include directory. There is a new make target 'make install-all-headers' that adds the whole content of the src/include tree to the installed fileset, for use by people who want to develop server-side code without keeping the complete source tree on hand. Cleaned up a whole lot of crufty and inconsistent header inclusions.
2001-02-10 03:31:31 +01:00
#include "postgres_fe.h"
Fixes for Cygwin, with help from Pete Forman <gsez020@kryten.bedford.waii.com>. Update the installation instructions (formerly misnamed "FAQ"), add configure checks for some headers rather than having users copy stubs manually (ugh!). Use Autoconf check for exe extension. This also avoids inheriting the value of $(X) from the environment.
2000-09-27 17:17:57 +02:00
> > > > If you want to put in security restrictions that are actually useful, > > > > where is the code to verify that PGPASSWORDFILE points at a > > > > non-world-readable file? That needs to be there now, not later, or > > > > we'll have people moaning about backward compatibility when we finally > > > > do plug that hole. Alvaro Herrera
2002-08-30 01:06:32 +02:00
#include <sys/stat.h>
Re-add getopt.h check, remove NT-specific tests for it.
1999-07-19 04:27:16 +02:00
#include <fcntl.h>
#include <ctype.h>
Remove replacement code for getaddrinfo. SUSv3, all targeted Unixes and modern Windows have getaddrinfo() and related interfaces. Drop the replacement implementation, and adjust some headers slightly to make sure that the APIs are visible everywhere using standard POSIX headers and names. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKG%2BL_3brvh%3D8e0BW_VfX9h7MtwgN%3DnFHP5o7X2oZucY9dg%40mail.gmail.com
2022-08-13 23:53:28 +02:00
#include <netdb.h>
Clean up compile warnings.
2002-08-18 02:06:01 +02:00
#include <time.h>
Set the close-on-exec flag for libpq's socket to the backend, to avoid any possible problems from child programs executed by the client app. Per suggestion from Elliot Lee of Red Hat.
2004-10-21 22:23:19 +02:00
#include <unistd.h>
Re-add getopt.h check, remove NT-specific tests for it.
1999-07-19 04:27:16 +02:00
Make the order of the header file includes consistent in non-backend modules. Similar to commit 7e735035f2, this commit makes the order of header file inclusion consistent for non-backend modules. In passing, fix the case where we were using angle brackets (<>) for the local module includes instead of quotes (""). Author: Vignesh C Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com
2019-10-23 06:08:53 +02:00
#include "common/ip.h"
#include "common/link-canary.h"
#include "common/scram-common.h"
#include "common/string.h"
#include "fe-auth.h"
Date: Sun, 16 Aug 1998 14:56:48 -0400 From: Tom Lane <tgl@sss.pgh.pa.us> Attached is a patch for this weekend's work on libpq. I've dealt with several issues: <for details: see message, in pgsql-patches archive for above data>
1998-08-17 05:50:43 +02:00
#include "libpq-fe.h"
#include "libpq-int.h"
Make the order of the header file includes consistent in non-backend modules. Similar to commit 7e735035f2, this commit makes the order of header file inclusion consistent for non-backend modules. In passing, fix the case where we were using angle brackets (<>) for the local module includes instead of quotes (""). Author: Vignesh C Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com
2019-10-23 06:08:53 +02:00
#include "mb/pg_wchar.h"
Put path configuration information into a .h file instead of cluttering several different module Makefiles with it. Also, do any adjustment of installation paths during configure, rather than every time Makefile.global is read.
2004-05-21 22:56:50 +02:00
#include "pg_config_paths.h"
Make the order of the header file includes consistent in non-backend modules. Similar to commit 7e735035f2, this commit makes the order of header file inclusion consistent for non-backend modules. In passing, fix the case where we were using angle brackets (<>) for the local module includes instead of quotes (""). Author: Vignesh C Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com
2019-10-23 06:08:53 +02:00
#include "port/pg_bswap.h"
Date: Sun, 16 Aug 1998 14:56:48 -0400 From: Tom Lane <tgl@sss.pgh.pa.us> Attached is a patch for this weekend's work on libpq. I've dealt with several issues: <for details: see message, in pgsql-patches archive for above data>
1998-08-17 05:50:43 +02:00
win32 cleanup
1998-07-03 06:29:04 +02:00
#ifdef WIN32
#include "win32.h"
Un-break MSVC build, per Andrew Dunstan.
2005-01-10 01:19:51 +01:00
#ifdef _WIN32_IE
#undef _WIN32_IE
#endif
Use SHGetFolderPath instead of SHGetSpecialFolderPath to find the APPDATA directory on Windows. Magnus Hagander
2005-01-26 20:24:03 +01:00
#define _WIN32_IE 0x0500
Un-break MSVC build, per Andrew Dunstan.
2005-01-10 01:19:51 +01:00
#ifdef near
#undef near
#endif
#define near
Adjust lookup of client-side profile files (.pgpass and so on) as per discussion on pgsql-hackers-win32 list. Documentation still needs to be tweaked --- I'm not sure how to refer to the APPDATA folder in user documentation.
2005-01-06 19:29:11 +01:00
#include <shlobj.h>
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
#include <mstcpip.h>
win32 cleanup
1998-07-03 06:29:04 +02:00
#else
Hi! Here is a patch to bring both libpq and psql to a state where it compiles on win32 (native) again. A lot of things have changed, and I have not been able to keep up with them all, so it has been broken for quite a while. After this patch, at least it compiles. It also talks "basic talk" to the server, but I have not yet tested all things. Sending queries, and using e.g. \d or \dt works fine. The rest will have to be tested further. It also bumps the version on libpq.dll to 7.0. Everything should be enclosed in #ifdef WIN32, unless I have missed something. Except for one or maybe two places where I have moved a #include that should not be used on win32 from the "global area" into a "#ifndef WIN32 area". //Magnus
2000-01-18 20:05:31 +01:00
#include <sys/socket.h>
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
#include <netdb.h>
Remove calls to getprotobyname(), which we now know leaks memory on some platforms --- and I also see that it is documented as not thread- safe on HPUX and possibly other platforms. No good reason not to just use IPPROTO_TCP constant from <netinet/in.h> instead.
2000-05-21 23:19:53 +02:00
#include <netinet/in.h>
Fixes for Cygwin, with help from Pete Forman <gsez020@kryten.bedford.waii.com>. Update the installation instructions (formerly misnamed "FAQ"), add configure checks for some headers rather than having users copy stubs manually (ugh!). Use Autoconf check for exe extension. This also avoids inheriting the value of $(X) from the environment.
2000-09-27 17:17:57 +02:00
#include <netinet/tcp.h>
#endif
shared build fails, but the rest compiles...formatting error in the cc -shared, I believe...
1996-11-03 08:14:32 +01:00
Allow libpq to do thread-safe SIGPIPE handling. This allows it to ignore SIGPIPE from send() in libpq, but terminate on any other SIGPIPE, unless the user installs their own signal handler. This is a minor fix because the only time you get SIGPIPE from libpq's send() is when the backend dies.
2004-01-09 03:02:43 +01:00
#ifdef ENABLE_THREAD_SAFETY
The attached patch updates the thread test program to run stand-alone on Windows. The test itself is bypassed in configure as discussed, and libpq has been updated appropriately to allow it to build in thread-safe mode. Dave Page
2005-08-23 23:02:05 +02:00
#ifdef WIN32
#include "pthread-win32.h"
#else
Allow libpq to do thread-safe SIGPIPE handling. This allows it to ignore SIGPIPE from send() in libpq, but terminate on any other SIGPIPE, unless the user installs their own signal handler. This is a minor fix because the only time you get SIGPIPE from libpq's send() is when the backend dies.
2004-01-09 03:02:43 +01:00
#include <pthread.h>
#endif
The attached patch updates the thread test program to run stand-alone on Windows. The test itself is bypassed in configure as discussed, and libpq has been updated appropriately to allow it to build in thread-safe mode. Dave Page
2005-08-23 23:02:05 +02:00
#endif
Allow libpq to do thread-safe SIGPIPE handling. This allows it to ignore SIGPIPE from send() in libpq, but terminate on any other SIGPIPE, unless the user installs their own signal handler. This is a minor fix because the only time you get SIGPIPE from libpq's send() is when the backend dies.
2004-01-09 03:02:43 +01:00
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
#ifdef USE_LDAP
#ifdef WIN32
#include <winldap.h>
#else
/* OpenLDAP deprecates RFC 1823, but we want standard conformance */
#define LDAP_DEPRECATED 1
#include <ldap.h>
typedef struct timeval LDAP_TIMEVAL;
#endif
static int ldapServiceLookup(const char *purl, PQconninfoOption *options,
PQExpBuffer errorMessage);
#endif
Adjust lookup of client-side profile files (.pgpass and so on) as per discussion on pgsql-hackers-win32 list. Documentation still needs to be tweaked --- I'm not sure how to refer to the APPDATA folder in user documentation.
2005-01-06 19:29:11 +01:00
#ifndef WIN32
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
#define PGPASSFILE ".pgpass"
Adjust lookup of client-side profile files (.pgpass and so on) as per discussion on pgsql-hackers-win32 list. Documentation still needs to be tweaked --- I'm not sure how to refer to the APPDATA folder in user documentation.
2005-01-06 19:29:11 +01:00
#else
Change Win32 client configuration files from *.txt to *.conf.
2005-01-14 01:25:56 +01:00
#define PGPASSFILE "pgpass.conf"
Adjust lookup of client-side profile files (.pgpass and so on) as per discussion on pgsql-hackers-win32 list. Documentation still needs to be tweaked --- I'm not sure how to refer to the APPDATA folder in user documentation.
2005-01-06 19:29:11 +01:00
#endif
Hi! Here is a patch to bring both libpq and psql to a state where it compiles on win32 (native) again. A lot of things have changed, and I have not been able to keep up with them all, so it has been broken for quite a while. After this patch, at least it compiles. It also talks "basic talk" to the server, but I have not yet tested all things. Sending queries, and using e.g. \d or \dt works fine. The rest will have to be tested further. It also bumps the version on libpq.dll to 7.0. Everything should be enclosed in #ifdef WIN32, unless I have missed something. Except for one or maybe two places where I have moved a #include that should not be used on win32 from the "global area" into a "#ifndef WIN32 area". //Magnus
2000-01-18 20:05:31 +01:00
Instead of sending application_name as a SET command after the connection is made, include it in the startup-packet options. This makes it work more like every other libpq connection option, in particular it now has the same response to RESET ALL as the rest. This also saves one network round trip for new applications using application_name. The cost is that if the server is pre-8.5, it'll reject the startup packet altogether, forcing us to retry the entire connection cycle. But on balance we shouldn't be optimizing that case in preference to the behavior with a new server, especially when doing so creates visible behavioral oddities. Per discussion.
2009-12-02 05:38:35 +01:00
/*
Stamp HEAD as 9.0devel, and update various places that were referring to 8.5 (hope I got 'em all). Per discussion, this release will be 9.0 not 8.5.
2010-02-17 05:19:41 +01:00
* Pre-9.0 servers will return this SQLSTATE if asked to set
Instead of sending application_name as a SET command after the connection is made, include it in the startup-packet options. This makes it work more like every other libpq connection option, in particular it now has the same response to RESET ALL as the rest. This also saves one network round trip for new applications using application_name. The cost is that if the server is pre-8.5, it'll reject the startup packet altogether, forcing us to retry the entire connection cycle. But on balance we shouldn't be optimizing that case in preference to the behavior with a new server, especially when doing so creates visible behavioral oddities. Per discussion.
2009-12-02 05:38:35 +01:00
* application_name in a startup packet. We hard-wire the value rather
* than looking into errcodes.h since it reflects historical behavior
* rather than that of the current code.
*/
#define ERRCODE_APPNAME_UNKNOWN "42704"
Add libpq warning message if the .pgpass-retrieved password fails. Add ERRCODE_INVALID_PASSWORD sqlstate error code.
2010-03-13 15:55:57 +01:00
/* This is part of the protocol so just define it */
#define ERRCODE_INVALID_PASSWORD "28P01"
Rewrite PQping to be more like what we agreed to last week. Basically, we want to distinguish all cases where the connection was not made from those where it was. A convenient proxy for this is to see if we got a message with a SQLSTATE code back from the postmaster. This presumes that the postmaster will always send us a SQLSTATE in a failure message, which is true for 7.4 and later postmasters in every case except fork failure. (We could possibly complicate the postmaster code to do something about that, but it seems not worth the trouble, especially since pg_ctl's response for that case should be to keep waiting anyway.) If we did get a SQLSTATE from the postmaster, there are basically only two cases, as per last week's discussion: ERRCODE_CANNOT_CONNECT_NOW and everything else. Any other error code implies that the postmaster is in principle willing to accept connections, it just didn't like or couldn't handle this particular request. We want to make a special case for ERRCODE_CANNOT_CONNECT_NOW so that "pg_ctl start -w" knows it should keep waiting. In passing, pick names for the enum constants that are a tad less likely to present collision hazards in future.
2010-11-27 07:30:34 +01:00
/* This too */
#define ERRCODE_CANNOT_CONNECT_NOW "57P03"
Add libpq warning message if the .pgpass-retrieved password fails. Add ERRCODE_INVALID_PASSWORD sqlstate error code.
2010-03-13 15:55:57 +01:00
Second try at fixing tcp_keepalives_idle option on Solaris. Buildfarm evidence shows that TCP_KEEPALIVE_THRESHOLD doesn't exist after all on Solaris < 11. This means we need to take positive action to prevent the TCP_KEEPALIVE code path from being taken on that platform. I've chosen to limit it with "&& defined(__darwin__)", since it's unclear that anyone else would follow Apple's precedent of spelling the symbol that way. Also, follow a suggestion from Michael Paquier of eliminating code duplication by defining a couple of intermediate symbols for the socket option. In passing, make some effort to reduce the number of translatable messages by replacing "setsockopt(foo) failed" with "setsockopt(%s) failed", etc, throughout the affected files. And update relevant documentation so that it doesn't claim to provide an exhaustive list of the possible socket option names. Like the previous commit (f0256c774), back-patch to all supported branches. Discussion: https://postgr.es/m/20170627163757.25161.528@wrigleys.postgresql.org
2017-06-28 18:30:16 +02:00
/*
* Cope with the various platform-specific ways to spell TCP keepalive socket
* options. This doesn't cover Windows, which as usual does its own thing.
*/
#if defined(TCP_KEEPIDLE)
/* TCP_KEEPIDLE is the name of this option on Linux and *BSD */
#define PG_TCP_KEEPALIVE_IDLE TCP_KEEPIDLE
#define PG_TCP_KEEPALIVE_IDLE_STR "TCP_KEEPIDLE"
#elif defined(TCP_KEEPALIVE_THRESHOLD)
/* TCP_KEEPALIVE_THRESHOLD is the name of this option on Solaris >= 11 */
#define PG_TCP_KEEPALIVE_IDLE TCP_KEEPALIVE_THRESHOLD
#define PG_TCP_KEEPALIVE_IDLE_STR "TCP_KEEPALIVE_THRESHOLD"
#elif defined(TCP_KEEPALIVE) && defined(__darwin__)
/* TCP_KEEPALIVE is the name of this option on macOS */
/* Caution: Solaris has this symbol but it means something different */
#define PG_TCP_KEEPALIVE_IDLE TCP_KEEPALIVE
#define PG_TCP_KEEPALIVE_IDLE_STR "TCP_KEEPALIVE"
#endif
Instead of sending application_name as a SET command after the connection is made, include it in the startup-packet options. This makes it work more like every other libpq connection option, in particular it now has the same response to RESET ALL as the rest. This also saves one network round trip for new applications using application_name. The cost is that if the server is pre-8.5, it'll reject the startup packet altogether, forcing us to retry the entire connection cycle. But on balance we shouldn't be optimizing that case in preference to the behavior with a new server, especially when doing so creates visible behavioral oddities. Per discussion.
2009-12-02 05:38:35 +01:00
/*
* fall back options if they are not specified by arguments or defined
* by environment variables
*/
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
#define DefaultHost "localhost"
#define DefaultOption ""
Add libpq parameter 'channel_binding'. Allow clients to require channel binding to enhance security against untrusted servers. Author: Jeff Davis Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel%40j-davis.com
2019-09-23 22:45:23 +02:00
#ifdef USE_SSL
#define DefaultChannelBinding "prefer"
#else
#define DefaultChannelBinding "disable"
#endif
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
#define DefaultTargetSessionAttrs "any"
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
#ifdef USE_SSL
Remove sslverify parameter again, replacing it with two new sslmode values: "verify-ca" and "verify-full". Since "prefer" remains the default, this will make certificate validation off by default, which should lead to less upgrade issues.
2009-04-24 11:43:10 +02:00
#define DefaultSSLMode "prefer"
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
#else
#define DefaultSSLMode "disable"
#endif
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
#ifdef ENABLE_GSS
#include "fe-gssapi-common.h"
#define DefaultGSSMode "prefer"
#else
#define DefaultGSSMode "disable"
#endif
Back out SSL changes. Newer patch available.
2002-06-14 06:09:37 +02:00
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
/* ----------
Remove most compile-time options, add a few runtime options to make up for it. In particular, no more compiled-in default for PGDATA or LIBDIR. Commands that need them need either invocation options or environment variables. PGPORT default is hardcoded as 5432, but overrideable with options or environment variables.
1996-11-14 11:25:54 +01:00
* Definition of the conninfo parameters and their fallback resources.
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
*
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
* If Environment-Var and Compiled-in are specified as NULL, no
* fallback is available. If after all no value can be determined
* for an option, an error is returned.
*
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
* The value for the username is treated specially in conninfo_add_defaults.
* If the value is not obtained any other way, the username is determined
* by pg_fe_getauthname().
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*
* The Label and Disp-Char entries are provided for applications that
* want to use PQconndefaults() to create a generic database connection
* dialog. Disp-Char is defined as follows:
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
* "" Normal input field
* "*" Password field - hide value
* "D" Debug option - don't show by default
*
* PQconninfoOptions[] is a constant static array that we use to initialize
* a dynamically allocated working copy. All the "val" fields in
* PQconninfoOptions[] *must* be NULL. In a working copy, non-null "val"
* fields point to malloc'd strings that should be freed when the working
* array is freed (see PQconninfoFree).
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
*
* The first part of each struct is identical to the one in libpq-fe.h,
* which is required since we memcpy() data between the two!
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
* ----------
*/
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
typedef struct _internalPQconninfoOption
{
char *keyword; /* The keyword of the option */
char *envvar; /* Fallback environment variable name */
char *compiled; /* Fallback compiled in default value */
Restructure libpq code to remove some duplicity There was some duplicate code to run SHOW transaction_read_only to determine whether the server is read-write or read-only. Reduce it by adding another state to the state machine. Author: Hari Babu Kommi Reviewed-by: Takayuki Tsunakawa, Álvaro Herrera Discussion: https://postgr.es/m/CAJrrPGe_qgdbbN+yBgEVpd+YLHXXjTruzk6RmTMhqrFig+32ag@mail.gmail.com
2019-09-10 17:13:29 +02:00
char *val; /* Option's current value, or NULL */
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
char *label; /* Label for field in connect dialog */
char *dispchar; /* Indicates how to display this field in a
* connect dialog. Values are: "" Display
* entered value as is "*" Password field -
* hide value "D" Debug option - don't show
* by default */
int dispsize; /* Field size in characters for dialog */
/* ---
* Anything above this comment must be synchronized with
* PQconninfoOption in libpq-fe.h, since we memcpy() data
* between them!
* ---
*/
off_t connofs; /* Offset into PGconn struct, -1 if not there */
} internalPQconninfoOption;
static const internalPQconninfoOption PQconninfoOptions[] = {
TNS: I prepared and tested a patch vs. 7.0.2, and it works fine. I've added another option which allows users to have their own service file in ~/.pg_service.conf, which might come handy sometimes. Mario Weilguni
2000-10-17 03:00:58 +02:00
{"service", "PGSERVICE", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Database-Service", "", 20, -1},
TNS: I prepared and tested a patch vs. 7.0.2, and it works fine. I've added another option which allows users to have their own service file in ~/.pg_service.conf, which might come handy sometimes. Mario Weilguni
2000-10-17 03:00:58 +02:00
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{"user", "PGUSER", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Database-User", "", 20,
offsetof(struct pg_conn, pguser)},
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
Missed some corner cases (PGSERVICE mostly)...
2003-04-28 06:52:13 +02:00
{"password", "PGPASSWORD", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Database-Password", "*", 20,
offsetof(struct pg_conn, pgpass)},
From: Dan McGuirk <mcguirk@indirect.com> Subject: [HACKERS] password authentication This patch adds support for plaintext password authentication. To use it, you add a line like host all 0.0.0.0 0.0.0.0 password pg_pwd.conf to your pg_hba.conf, where 'pg_pwd.conf' is the name of a file containing the usernames and password hashes in the format of the first two fields of a Unix /etc/passwd file. (Of course, you can use a specific database name or IP instead.) Then, to connect with a password through libpq, you use the PQconnectdb() function, specifying the "password=" tag in the connect string and also adding the tag "authtype=password". I also added a command-line switch '-u' to psql that tells it to prompt for a username and password and use password authentication.
1997-03-12 22:23:16 +01:00
Allow password file name to be specified as a libpq connection parameter. Formerly an alternate password file could only be selected via the environment variable PGPASSFILE; now it can also be selected via a new connection parameter "passfile", corresponding to the conventions for most other connection parameters. There was some concern about this creating a security weakness, but it was agreed that that argument was pretty thin, and there are clear use-cases for handling password files this way. Julian Markwort, reviewed by Fabien Coelho, some adjustments by me Discussion: https://postgr.es/m/a4b4f4f1-7b58-a0e8-5268-5f7db8e8ccaa@uni-muenster.de
2017-01-24 23:06:21 +01:00
{"passfile", "PGPASSFILE", NULL, NULL,
"Database-Password-File", "", 64,
offsetof(struct pg_conn, pgpassfile)},
Expose the default for channel_binding in PQconndefaults(). If there's a static default value for a connection option, it should be shown in the PQconninfoOptions array. Daniele Varrazzo Discussion: https://postgr.es/m/CA+mi_8Zo8Rgn7p+6ZRY7QdDu+23ukT9AvoHNyPbgKACxwgGhZA@mail.gmail.com
2020-12-28 18:13:40 +01:00
{"channel_binding", "PGCHANNELBINDING", DefaultChannelBinding, NULL,
Fix dispsize for libpq connection parameters channel_binding and gssencmode channel_binding's longest allowed value is not "7", it is actually "8". gssencmode also got that wrong. A similar mistake has been fixed as of f4051e3. Backpatch down to v12, where gssencmode has been introduced. Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/20200128053633.GD1552@paquier.xyz Backpatch-through: 12
2020-01-29 07:08:19 +01:00
"Channel-Binding", "", 8, /* sizeof("require") == 8 */
Add libpq parameter 'channel_binding'. Allow clients to require channel binding to enhance security against untrusted servers. Author: Jeff Davis Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel%40j-davis.com
2019-09-23 22:45:23 +02:00
offsetof(struct pg_conn, channel_binding)},
Add includes for prototype using timeval.
2002-08-18 03:35:40 +02:00
{"connect_timeout", "PGCONNECT_TIMEOUT", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Connect-timeout", "", 10, /* strlen(INT32_MAX) == 10 */
offsetof(struct pg_conn, connect_timeout)},
Add libpq connection timeout parameter. Denis A Ustimenko
2002-08-17 14:33:18 +02:00
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{"dbname", "PGDATABASE", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Database-Name", "", 20,
offsetof(struct pg_conn, dbName)},
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
Add Unix domain socket support, from Goran Thyni, goran@bildbasen.se
1997-11-07 21:52:15 +01:00
{"host", "PGHOST", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Database-Host", "", 40,
offsetof(struct pg_conn, pghost)},
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
{"hostaddr", "PGHOSTADDR", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Database-Host-IP-Address", "", 45,
offsetof(struct pg_conn, pghostaddr)},
Only set the database name if we find a match in the services file.
2003-01-08 17:21:53 +01:00
The heralded `Grand Unified Configuration scheme' (GUC) That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
2000-05-31 02:28:42 +02:00
{"port", "PGPORT", DEF_PGPORT_STR, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Database-Port", "", 6,
offsetof(struct pg_conn, pgport)},
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
Set psql client encoding from locale by default Add a new libpq connection option client_encoding (which includes the existing PGCLIENTENCODING environment variable), which besides an encoding name accepts a special value "auto" that tries to determine the encoding from the locale in the client's environment, using the mechanisms that have been in use in initdb. psql sets this new connection option to "auto" when running from a terminal and not overridden by setting PGCLIENTENCODING. original code by Heikki Linnakangas, with subsequent contributions by Jaime Casanova, Peter Eisentraut, Stephen Frost, Ibrar Ahmed
2011-02-19 07:54:58 +01:00
{"client_encoding", "PGCLIENTENCODING", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Client-Encoding", "", 10,
offsetof(struct pg_conn, client_encoding_initial)},
Set psql client encoding from locale by default Add a new libpq connection option client_encoding (which includes the existing PGCLIENTENCODING environment variable), which besides an encoding name accepts a special value "auto" that tries to determine the encoding from the locale in the client's environment, using the mechanisms that have been in use in initdb. psql sets this new connection option to "auto" when running from a terminal and not overridden by setting PGCLIENTENCODING. original code by Heikki Linnakangas, with subsequent contributions by Jaime Casanova, Peter Eisentraut, Stephen Frost, Ibrar Ahmed
2011-02-19 07:54:58 +01:00
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{"options", "PGOPTIONS", DefaultOption, NULL,
libpq: Change "options" dispchar to normal libpq connection options as returned by PQconndefaults() have a "dispchar" field that determines (among other things) whether an option is a "debug" option, which shouldn't be shown by default to clients. postgres_fdw makes use of that to control which connection options to accept from a foreign server configuration. Curiously, the "options" option, which allows passing configuration settings to the backend server, was listed as a debug option, which prevented it from being used by postgres_fdw. Maybe it was once meant for debugging, but it's clearly in general use nowadays. So change the dispchar for it to be the normal non-debug case. Also remove the "debug" reference from its label field. Reported-by: Shinoda, Noriyoshi <noriyoshi.shinoda@hpe.com>
2018-09-07 15:01:25 +02:00
"Backend-Options", "", 40,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
offsetof(struct pg_conn, pgoptions)},
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
{"application_name", "PGAPPNAME", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Application-Name", "", 64,
offsetof(struct pg_conn, appname)},
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
{"fallback_application_name", NULL, NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Fallback-Application-Name", "", 64,
offsetof(struct pg_conn, fbappname)},
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
{"keepalives", NULL, NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"TCP-Keepalives", "", 1, /* should be just '0' or '1' */
offsetof(struct pg_conn, keepalives)},
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
{"keepalives_idle", NULL, NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"TCP-Keepalives-Idle", "", 10, /* strlen(INT32_MAX) == 10 */
offsetof(struct pg_conn, keepalives_idle)},
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
{"keepalives_interval", NULL, NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"TCP-Keepalives-Interval", "", 10, /* strlen(INT32_MAX) == 10 */
offsetof(struct pg_conn, keepalives_interval)},
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
{"keepalives_count", NULL, NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"TCP-Keepalives-Count", "", 10, /* strlen(INT32_MAX) == 10 */
offsetof(struct pg_conn, keepalives_count)},
SSL patch from Magnus
2000-08-30 16:54:24 +02:00
Add support TCP user timeout in libpq and the backend server Similarly to the set of parameters for keepalive, a connection parameter for libpq is added as well as a backend GUC, called tcp_user_timeout. Increasing the TCP user timeout is useful to allow a connection to survive extended periods without end-to-end connection, and decreasing it allows application to fail faster. By default, the parameter is 0, which makes the connection use the system default, and follows a logic close to the keepalive parameters in its handling. When connecting through a Unix-socket domain, the parameters have no effect. Author: Ryohei Nagaura Reviewed-by: Fabien Coelho, Robert Haas, Kyotaro Horiguchi, Kirk Jamison, Mikalai Keida, Takayuki Tsunakawa, Andrei Yahorau Discussion: https://postgr.es/m/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04
2019-04-06 08:23:37 +02:00
{"tcp_user_timeout", NULL, NULL, NULL,
"TCP-User-Timeout", "", 10, /* strlen(INT32_MAX) == 10 */
offsetof(struct pg_conn, pgtcp_user_timeout)},
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
/*
Support specifying filename for SSL certificate, key, root certificate store and certificate revokation list by using connection parameters or environment variables. Original patch by Mark Woodward, heavily reworked by Alvaro Herrera and Magnus Hagander.
2008-12-15 11:28:22 +01:00
* ssl options are allowed even without client SSL support because the
* client can still handle SSL modes "disable" and "allow". Other
* parameters have no effect on non-SSL connections, so there is no reason
* to exclude them since none of them are mandatory.
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
*/
{"sslmode", "PGSSLMODE", DefaultSSLMode, NULL,
Fix advertised dispsize for libpq's sslmode connection parameter. "8" was correct back when "disable" was the longest allowed value, but since "verify-full" was added, it should be "12". Given the lack of complaints, I wouldn't be surprised if nobody is actually using these values ... but still, if they're in the API, they should be right. Noticed while pursuing a different problem. It's been wrong for quite a long time, so back-patch to all supported branches.
2014-03-17 02:43:40 +01:00
"SSL-Mode", "", 12, /* sizeof("verify-full") == 12 */
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
offsetof(struct pg_conn, sslmode)},
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
Revert changes for SSL compression in libpq This partially reverts 096bbf7 and 9d2d457, undoing the libpq changes as it could cause breakages in distributions that share one single libpq version across multiple major versions of Postgres for extensions and applications linking to that. Note that the backend is unchanged here, and it still disables SSL compression while simplifying the underlying catalogs that tracked if compression was enabled or not for a SSL connection. Per discussion with Tom Lane and Daniel Gustafsson. Discussion: https://postgr.es/m/YEbq15JKJwIX+S6m@paquier.xyz
2021-03-10 01:35:42 +01:00
{"sslcompression", "PGSSLCOMPRESSION", "0", NULL,
"SSL-Compression", "", 1,
offsetof(struct pg_conn, sslcompression)},
Add libpq connection option to disable SSL compression This can be used to remove the overhead of SSL compression on fast networks. Laurenz Albe
2011-11-28 13:13:42 +01:00
Support specifying filename for SSL certificate, key, root certificate store and certificate revokation list by using connection parameters or environment variables. Original patch by Mark Woodward, heavily reworked by Alvaro Herrera and Magnus Hagander.
2008-12-15 11:28:22 +01:00
{"sslcert", "PGSSLCERT", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"SSL-Client-Cert", "", 64,
offsetof(struct pg_conn, sslcert)},
Support specifying filename for SSL certificate, key, root certificate store and certificate revokation list by using connection parameters or environment variables. Original patch by Mark Woodward, heavily reworked by Alvaro Herrera and Magnus Hagander.
2008-12-15 11:28:22 +01:00
{"sslkey", "PGSSLKEY", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"SSL-Client-Key", "", 64,
offsetof(struct pg_conn, sslkey)},
Support specifying filename for SSL certificate, key, root certificate store and certificate revokation list by using connection parameters or environment variables. Original patch by Mark Woodward, heavily reworked by Alvaro Herrera and Magnus Hagander.
2008-12-15 11:28:22 +01:00
libpq should expose GSS-related parameters even when not implemented. We realized years ago that it's better for libpq to accept all connection parameters syntactically, even if some are ignored or restricted due to lack of the feature in a particular build. However, that lesson from the SSL support was for some reason never applied to the GSSAPI support. This is causing various buildfarm members to have problems with a test case added by commit 6136e94dc, and it's just a bad idea from a user-experience standpoint anyway, so fix it. While at it, fix some places where parameter-related infrastructure was added with the aid of a dartboard, or perhaps with the aid of the anti-pattern "add new stuff at the end". It should be safe to rearrange the contents of struct pg_conn even in released branches, since that's private to libpq (and we'd have to move some fields in some builds to fix this, anyway). Back-patch to all supported branches. Discussion: https://postgr.es/m/11297.1576868677@sss.pgh.pa.us
2019-12-20 21:34:07 +01:00
{"sslpassword", NULL, NULL, NULL,
"SSL-Client-Key-Password", "*", 20,
offsetof(struct pg_conn, sslpassword)},
Support specifying filename for SSL certificate, key, root certificate store and certificate revokation list by using connection parameters or environment variables. Original patch by Mark Woodward, heavily reworked by Alvaro Herrera and Magnus Hagander.
2008-12-15 11:28:22 +01:00
{"sslrootcert", "PGSSLROOTCERT", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"SSL-Root-Certificate", "", 64,
offsetof(struct pg_conn, sslrootcert)},
Support specifying filename for SSL certificate, key, root certificate store and certificate revokation list by using connection parameters or environment variables. Original patch by Mark Woodward, heavily reworked by Alvaro Herrera and Magnus Hagander.
2008-12-15 11:28:22 +01:00
{"sslcrl", "PGSSLCRL", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"SSL-Revocation-List", "", 64,
offsetof(struct pg_conn, sslcrl)},
Support specifying filename for SSL certificate, key, root certificate store and certificate revokation list by using connection parameters or environment variables. Original patch by Mark Woodward, heavily reworked by Alvaro Herrera and Magnus Hagander.
2008-12-15 11:28:22 +01:00
Allow specifying CRL directory Add another method to specify CRLs, hashed directory method, for both server and client side. This offers a means for server or libpq to load only CRLs that are required to verify a certificate. The CRL directory is specifed by separate GUC variables or connection options ssl_crl_dir and sslcrldir, alongside the existing ssl_crl_file and sslcrl, so both methods can be used at the same time. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/20200731.173911.904649928639357911.horikyota.ntt@gmail.com
2021-02-18 07:59:10 +01:00
{"sslcrldir", "PGSSLCRLDIR", NULL, NULL,
"SSL-Revocation-List-Dir", "", 64,
offsetof(struct pg_conn, sslcrldir)},
libpq: Set Server Name Indication (SNI) for SSL connections By default, have libpq set the TLS extension "Server Name Indication" (SNI). This allows an SNI-aware SSL proxy to route connections. (This requires a proxy that is aware of the PostgreSQL protocol, not just any SSL proxy.) In the future, this could also allow the server to use different SSL certificates for different host specifications. (That would require new server functionality. This would be the client-side functionality for that.) Since SNI makes the host name appear in cleartext in the network traffic, this might be undesirable in some cases. Therefore, also add a libpq connection option "sslsni" to turn it off. Discussion: https://www.postgresql.org/message-id/flat/7289d5eb-62a5-a732-c3b9-438cee2cb709%40enterprisedb.com
2021-04-07 15:11:41 +02:00
{"sslsni", "PGSSLSNI", "1", NULL,
"SSL-SNI", "", 1,
offsetof(struct pg_conn, sslsni)},
Add server authentication over Unix-domain sockets This adds a libpq connection parameter requirepeer that specifies the user name that the server process is expected to run under. reviewed by KaiGai Kohei
2010-07-18 13:37:26 +02:00
{"requirepeer", "PGREQUIREPEER", NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Require-Peer", "", 10,
offsetof(struct pg_conn, requirepeer)},
Add server authentication over Unix-domain sockets This adds a libpq connection parameter requirepeer that specifies the user name that the server process is expected to run under. reviewed by KaiGai Kohei
2010-07-18 13:37:26 +02:00
Change libpq's default ssl_min_protocol_version to TLSv1.2. When we initially created this parameter, in commit ff8ca5fad, we left the default as "allow any protocol version" on grounds of backwards compatibility. However, that's inconsistent with the backend's default since b1abfec82; protocol versions prior to 1.2 are not considered very secure; and OpenSSL has had TLSv1.2 support since 2012, so the number of PG servers that need a lesser minimum is probably quite small. On top of those things, it emerges that some popular distros (including Debian and RHEL) set MinProtocol=TLSv1.2 in openssl.cnf. Thus, far from having "allow any protocol version" behavior in practice, what we actually have as things stand is a platform-dependent lower limit. So, change our minds and set the min version to TLSv1.2. Anybody wanting to connect with a new libpq to a pre-2012 server can either set ssl_min_protocol_version=TLSv1 or accept the fallback to non-SSL. Back-patch to v13 where the aforementioned patches appeared. Patch by me, reviewed by Daniel Gustafsson Discussion: https://postgr.es/m/a9408304-4381-a5af-d259-e55d349ae4ce@2ndquadrant.com
2020-06-27 18:20:33 +02:00
{"ssl_min_protocol_version", "PGSSLMINPROTOCOLVERSION", "TLSv1.2", NULL,
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
"SSL-Minimum-Protocol-Version", "", 8, /* sizeof("TLSv1.x") == 8 */
Rename connection parameters to control min/max SSL protocol version in libpq The libpq parameters ssl{max|min}protocolversion are renamed to use underscores, to become ssl_{max|min}_protocol_version. The related environment variables still use the names introduced in commit ff8ca5f that added the feature. Per complaint from Peter Eisentraut (this was also mentioned by me in the original patch review but the issue got discarded). Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com
2020-04-30 06:39:10 +02:00
offsetof(struct pg_conn, ssl_min_protocol_version)},
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
Rename connection parameters to control min/max SSL protocol version in libpq The libpq parameters ssl{max|min}protocolversion are renamed to use underscores, to become ssl_{max|min}_protocol_version. The related environment variables still use the names introduced in commit ff8ca5f that added the feature. Per complaint from Peter Eisentraut (this was also mentioned by me in the original patch review but the issue got discarded). Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com
2020-04-30 06:39:10 +02:00
{"ssl_max_protocol_version", "PGSSLMAXPROTOCOLVERSION", NULL, NULL,
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
"SSL-Maximum-Protocol-Version", "", 8, /* sizeof("TLSv1.x") == 8 */
Rename connection parameters to control min/max SSL protocol version in libpq The libpq parameters ssl{max|min}protocolversion are renamed to use underscores, to become ssl_{max|min}_protocol_version. The related environment variables still use the names introduced in commit ff8ca5f that added the feature. Per complaint from Peter Eisentraut (this was also mentioned by me in the original patch review but the issue got discarded). Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com
2020-04-30 06:39:10 +02:00
offsetof(struct pg_conn, ssl_max_protocol_version)},
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
/*
libpq should expose GSS-related parameters even when not implemented. We realized years ago that it's better for libpq to accept all connection parameters syntactically, even if some are ignored or restricted due to lack of the feature in a particular build. However, that lesson from the SSL support was for some reason never applied to the GSSAPI support. This is causing various buildfarm members to have problems with a test case added by commit 6136e94dc, and it's just a bad idea from a user-experience standpoint anyway, so fix it. While at it, fix some places where parameter-related infrastructure was added with the aid of a dartboard, or perhaps with the aid of the anti-pattern "add new stuff at the end". It should be safe to rearrange the contents of struct pg_conn even in released branches, since that's private to libpq (and we'd have to move some fields in some builds to fix this, anyway). Back-patch to all supported branches. Discussion: https://postgr.es/m/11297.1576868677@sss.pgh.pa.us
2019-12-20 21:34:07 +01:00
* As with SSL, all GSS options are exposed even in builds that don't have
* support.
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
*/
Handle errors during GSSAPI startup better There was some confusion over the format of the error message returned from the server during GSSAPI startup; specifically, it was expected that a length would be returned when, in reality, at this early stage in the startup sequence, no length is returned from the server as part of an error message. Correct the client-side code for dealing with error messages sent by the server during startup by simply reading what's available into our buffer, after we've discovered it's an error message, and then reporting back what was returned. In passing, also add in documentation of the environment variable PGGSSENCMODE which was missed previously, and adjust the code to look for the PGGSSENCMODE variable (the environment variable change was missed in the prior GSSMODE -> GSSENCMODE commit). Error-handling issue discovered by Peter Eisentraut, the rest were items discovered during testing of the error handling.
2019-04-05 04:52:42 +02:00
{"gssencmode", "PGGSSENCMODE", DefaultGSSMode, NULL,
Fix dispsize for libpq connection parameters channel_binding and gssencmode channel_binding's longest allowed value is not "7", it is actually "8". gssencmode also got that wrong. A similar mistake has been fixed as of f4051e3. Backpatch down to v12, where gssencmode has been introduced. Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/20200128053633.GD1552@paquier.xyz Backpatch-through: 12
2020-01-29 07:08:19 +01:00
"GSSENC-Mode", "", 8, /* sizeof("disable") == 8 */
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
offsetof(struct pg_conn, gssencmode)},
Add support for GSSAPI authentication. Documentation still being written, will be committed later. Henry B. Hotz and Magnus Hagander
2007-07-10 15:14:22 +02:00
/* Kerberos and GSSAPI authentication support specifying the service name */
Allow kerberos name and username case sensitivity to be specified from postgresql.conf. --------------------------------------------------------------------------- Here's an updated version of the patch, with the following changes: 1) No longer uses "service name" as "application version". It's instead hardcoded as "postgres". It could be argued that this part should be backpatched to 8.0, but it doesn't make a big difference until you can start changing it with GUC / connection parameters. This change only affects kerberos 5, not 4. 2) Now downcases kerberos usernames when the client is running on win32. 3) Adds guc option for "krb_caseins_users" to make the server ignore case mismatch which is required by some KDCs such as Active Directory. Off by default, per discussion with Tom. This change only affects kerberos 5, not 4. 4) Updated so it doesn't conflict with the rendevouz/bonjour patch already in ;-) Magnus Hagander
2005-06-04 22:42:43 +02:00
{"krbsrvname", "PGKRBSRVNAME", PG_KRB_SRVNAM, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Kerberos-service-name", "", 20,
offsetof(struct pg_conn, krbsrvname)},
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
SSPI authentication on Windows. GSSAPI compatible client when doing Kerberos against a Unix server, and Windows-specific server-side authentication using SSPI "negotiate" method (Kerberos or NTLM). Only builds properly with MSVC for now.
2007-07-23 12:16:54 +02:00
{"gsslib", "PGGSSLIB", NULL, NULL,
Fix dispsize for libpq connection parameters channel_binding and gssencmode channel_binding's longest allowed value is not "7", it is actually "8". gssencmode also got that wrong. A similar mistake has been fixed as of f4051e3. Backpatch down to v12, where gssencmode has been introduced. Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/20200128053633.GD1552@paquier.xyz Backpatch-through: 12
2020-01-29 07:08:19 +01:00
"GSS-library", "", 7, /* sizeof("gssapi") == 7 */
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
offsetof(struct pg_conn, gsslib)},
SSPI authentication on Windows. GSSAPI compatible client when doing Kerberos against a Unix server, and Windows-specific server-side authentication using SSPI "negotiate" method (Kerberos or NTLM). Only builds properly with MSVC for now.
2007-07-23 12:16:54 +02:00
Introduce Streaming Replication. This includes two new kinds of postmaster processes, walsenders and walreceiver. Walreceiver is responsible for connecting to the primary server and streaming WAL to disk, while walsender runs in the primary server and streams WAL from disk to the client. Documentation still needs work, but the basics are there. We will probably pull the replication section to a new chapter later on, as well as the sections describing file-based replication. But let's do that as a separate patch, so that it's easier to see what has been added/changed. This patch also adds a new section to the chapter about FE/BE protocol, documenting the protocol used by walsender/walreceivxer. Bump catalog version because of two new functions, pg_last_xlog_receive_location() and pg_last_xlog_replay_location(), for monitoring the progress of replication. Fujii Masao, with additional hacking by me
2010-01-15 10:19:10 +01:00
{"replication", NULL, NULL, NULL,
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
"Replication", "D", 5,
offsetof(struct pg_conn, replication)},
Introduce Streaming Replication. This includes two new kinds of postmaster processes, walsenders and walreceiver. Walreceiver is responsible for connecting to the primary server and streaming WAL to disk, while walsender runs in the primary server and streams WAL from disk to the client. Documentation still needs work, but the basics are there. We will probably pull the replication section to a new chapter later on, as well as the sections describing file-based replication. But let's do that as a separate patch, so that it's easier to see what has been added/changed. This patch also adds a new section to the chapter about FE/BE protocol, documenting the protocol used by walsender/walreceivxer. Bump catalog version because of two new functions, pg_last_xlog_receive_location() and pg_last_xlog_replay_location(), for monitoring the progress of replication. Fujii Masao, with additional hacking by me
2010-01-15 10:19:10 +01:00
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
{"target_session_attrs", "PGTARGETSESSIONATTRS",
DefaultTargetSessionAttrs, NULL,
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
"Target-Session-Attrs", "", 15, /* sizeof("prefer-standby") = 15 */
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
offsetof(struct pg_conn, target_session_attrs)},
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
/* Terminating entry --- MUST BE LAST */
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{NULL, NULL, NULL, NULL,
NULL, NULL, 0}
};
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
static const PQEnvironmentOption EnvironmentOptions[] =
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Add other initialization environment variables: PGCOSTHEAP, PGCOSTINDEX, PGRPLANS, PGGEQO (PGDATESTYLE, PGTZ already defined)
1997-11-14 16:38:31 +01:00
/* common user-interface settings */
{
"PGDATESTYLE", "datestyle"
},
{
"PGTZ", "timezone"
},
/* internal performance-related settings */
{
"PGGEQO", "geqo"
},
Add PGTZ environment variable to initialization code. Rename PG_DATESTYLE to PGDATESTYLE environment variable. Move environment variable code to a different place so it now works! Note that regression tests can now run with "setenv PGTZ PST8PDT" at the frontend rather than requiring the backend to have TZ set.
1997-11-10 16:41:58 +01:00
{
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
NULL, NULL
Add PGTZ environment variable to initialization code. Rename PG_DATESTYLE to PGDATESTYLE environment variable. Move environment variable code to a different place so it now works! Note that regression tests can now run with "setenv PGTZ PST8PDT" at the frontend rather than requiring the backend to have TZ set.
1997-11-10 16:41:58 +01:00
}
- Move most of the I/O in both libpq and the backend to a set of common routines in pqcomprim.c (pq communication primitives). Not all adapted to it yet, but it's a start. - Rewritten some of those routines, to write/read bigger chunks of data, precomputing stuff in buffers instead of sending out byte by byte. - As a consequence, I need to know the endianness of the machine. Currently I rely on getting it from machine/endian.h, but this may not be available everywhere? (Who the hell thought it was a good idea to pass integers to the backend the other way around than the normal network byte order? *argl*) - Libpq looks in the environment for magic variables, and upon establishing a connection to the backend, sends it queries of the form "SET var_name TO 'var_value'". This needs a change in the backend parser (Mr. Parser, are you there? :) - Currently it looks for two Env-Vars, namely PG_DATEFORMAT and PG_FLOATFORMAT. What else makes sense? PG_TIMEFORMAT? PG_TIMEZONE? From: "Martin J. Laubach" <mjl@wwx.vip.at>
1997-03-18 21:15:39 +01:00
};
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
/* The connection URI must start with either of the following designators: */
static const char uri_designator[] = "postgresql://";
static const char short_uri_designator[] = "postgres://";
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
static bool connectOptions1(PGconn *conn, const char *conninfo);
static bool connectOptions2(PGconn *conn);
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
static int connectDBStart(PGconn *conn);
static int connectDBComplete(PGconn *conn);
Add PQping and PQpingParams to libpq to allow detection of the server's status, including a status where the server is running but refuses a postgres connection. Have pg_ctl use this new function. This fixes the case where pg_ctl reports that the server is not running (cannot connect) but in fact it is running.
2010-11-25 19:09:38 +01:00
static PGPing internal_ping(PGconn *conn);
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
static PGconn *makeEmptyPGconn(void);
libpq: drop pending pipelined commands in pqDropConnection(). The original coding did this in pqDropServerData(), which seems fairly backwards. Pending commands are more like already-queued output data, which is dropped in pqDropConnection(). Moving the operation means that we clear the command queue immediately upon detecting connection drop, which improves the sanity of subsequent behavior. In particular this eliminates duplicated error message text as a consequence of code added in b15f25446, which supposed that a nonempty command queue must mean the prior operation is still active. There might be an argument for backpatching this to v14; but as with b15f25446, I'm unsure about interactions with 618c16707. For now, given the lack of complaints about v14's behavior, leave it alone. Per report from Peter Eisentraut. Discussion: https://postgr.es/m/de57761c-b99b-3435-b0a6-474c72b1149a@enterprisedb.com
2022-05-12 18:42:29 +02:00
static void pqFreeCommandQueue(PGcmdQueueEntry *queue);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
static bool fillPGconn(PGconn *conn, PQconninfoOption *connOptions);
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
static void freePGconn(PGconn *conn);
static void closePGconn(PGconn *conn);
In libpq, don't look up all the hostnames at once. Historically, we looked up the target hostname in connectDBStart, so that PQconnectPoll did not need to do DNS name resolution. The patches that added multiple-target-host support to libpq preserved this division of labor; but it's really nonsensical now, because it means that if any one of the target hosts fails to resolve in DNS, the connection fails. That negates the no-single-point-of-failure goal of the feature. Additionally, DNS lookups aren't exactly cheap, but the code did them all even if the first connection attempt succeeds. Hence, rearrange so that PQconnectPoll does the lookups, and only looks up a hostname when it's time to try that host. This does mean that PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid that, you should be using hostaddr, as the documentation has always specified. It seems fairly unlikely that any applications would really care whether the lookup occurs inside PQconnectStart or PQconnectPoll. In addition to calling out that fact explicitly, do some other minor wordsmithing in the docs around the multiple-target-host feature. Since this seems like a bug in the multiple-target-host feature, backpatch to v10 where that was introduced. In the back branches, avoid moving any existing fields of struct pg_conn, just in case any third-party code is looking into that struct. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
2018-08-23 22:39:19 +02:00
static void release_conn_addrinfo(PGconn *conn);
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
static void sendTerminateConn(PGconn *conn);
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
static PQconninfoOption *conninfo_init(PQExpBuffer errorMessage);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
static PQconninfoOption *parse_connection_string(const char *conninfo,
PQExpBuffer errorMessage, bool use_defaults);
Revert "psql: fix \connect with URIs and conninfo strings" This reverts commit fcef1617295c074f2684c887627184d2fc26ac04, about which both the buildfarm and my local machine are very unhappy.
2015-04-02 16:10:22 +02:00
static int uri_prefix_length(const char *connstr);
static bool recognized_connection_string(const char *connstr);
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
static PQconninfoOption *conninfo_parse(const char *conninfo,
Get rid of pgpass_from_client tracking inside libpq --- given the conclusion that presence of the password in the conninfo string must be checked *before* risking a connection attempt, there is no point in checking it afterwards. This makes the specification of PQconnectionUsedPassword() a bit simpler and perhaps more generally useful, too.
2008-09-22 16:21:44 +02:00
PQExpBuffer errorMessage, bool use_defaults);
Fully const-ify PQconnectdbParams, PQconnectStartParams, and PQpingParams. The keywords and values arguments of these functions are more properly declared "const char * const *" than just "const char **". Lionel Elie Mamane, reviewed by Craig Ringer
2011-09-26 00:52:48 +02:00
static PQconninfoOption *conninfo_array_parse(const char *const *keywords,
const char *const *values, PQExpBuffer errorMessage,
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
bool use_defaults, int expand_dbname);
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
static bool conninfo_add_defaults(PQconninfoOption *options,
PQExpBuffer errorMessage);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
static PQconninfoOption *conninfo_uri_parse(const char *uri,
PQExpBuffer errorMessage, bool use_defaults);
static bool conninfo_uri_parse_options(PQconninfoOption *options,
const char *uri, PQExpBuffer errorMessage);
static bool conninfo_uri_parse_params(char *params,
PQconninfoOption *connOptions,
PQExpBuffer errorMessage);
static char *conninfo_uri_decode(const char *str, PQExpBuffer errorMessage);
static bool get_hexdigit(char digit, int *value);
static const char *conninfo_getval(PQconninfoOption *connOptions,
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
const char *keyword);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
static PQconninfoOption *conninfo_storeval(PQconninfoOption *connOptions,
const char *keyword, const char *value,
PQExpBuffer errorMessage, bool ignoreMissing, bool uri_decode);
static PQconninfoOption *conninfo_find(PQconninfoOption *connOptions,
const char *keyword);
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
static void defaultNoticeReceiver(void *arg, const PGresult *res);
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
static void defaultNoticeProcessor(void *arg, const char *message);
TNS: I prepared and tested a patch vs. 7.0.2, and it works fine. I've added another option which allows users to have their own service file in ~/.pg_service.conf, which might come handy sometimes. Mario Weilguni
2000-10-17 03:00:58 +02:00
static int parseServiceInfo(PQconninfoOption *options,
PQExpBuffer errorMessage);
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
static int parseServiceFile(const char *serviceFile,
const char *service,
PQconninfoOption *options,
PQExpBuffer errorMessage,
bool *group_found);
Add some const decorations to prototypes Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
2017-10-31 15:34:31 +01:00
static char *pwdfMatchesString(char *buf, const char *token);
static char *passwordFromFile(const char *hostname, const char *port, const char *dbname,
const char *username, const char *pgpassfile);
Allow password file name to be specified as a libpq connection parameter. Formerly an alternate password file could only be selected via the environment variable PGPASSFILE; now it can also be selected via a new connection parameter "passfile", corresponding to the conventions for most other connection parameters. There was some concern about this creating a security weakness, but it was agreed that that argument was pretty thin, and there are clear use-cases for handling password files this way. Julian Markwort, reviewed by Fabien Coelho, some adjustments by me Discussion: https://postgr.es/m/a4b4f4f1-7b58-a0e8-5268-5f7db8e8ccaa@uni-muenster.de
2017-01-24 23:06:21 +01:00
static void pgpassfileWarning(PGconn *conn);
Code review for recent libpq changes. Be more careful about error handling in SIGPIPE processing; avoid unnecessary pollution of application link-symbol namespace; spell 'pointer to function' in the conventional way.
2004-12-03 00:20:21 +01:00
static void default_threadlock(int acquire);
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
static bool sslVerifyProtocolVersion(const char *version);
static bool sslVerifyProtocolRange(const char *min, const char *max);
Code review for recent libpq changes. Be more careful about error handling in SIGPIPE processing; avoid unnecessary pollution of application link-symbol namespace; spell 'pointer to function' in the conventional way.
2004-12-03 00:20:21 +01:00
/* global variable because fe-auth.c needs to access it */
pgthreadlock_t pg_g_threadlock = default_threadlock;
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
Allow libpq to do thread-safe SIGPIPE handling. This allows it to ignore SIGPIPE from send() in libpq, but terminate on any other SIGPIPE, unless the user installs their own signal handler. This is a minor fix because the only time you get SIGPIPE from libpq's send() is when the backend dies.
2004-01-09 03:02:43 +01:00
Centralize libpq's low-level code for dropping a connection. Create an internal function pqDropConnection that does the physical socket close and cleans up closely-associated state. This removes a bunch of ad hoc, not always consistent closure code. The ulterior motive is to have a single place to wait for a spawned child backend to exit, but this seems like good cleanup even if that never happens. I went back and forth on whether to include "conn->status = CONNECTION_BAD" in pqDropConnection's actions, but for the moment decided not to. Only a minority of the call sites actually want that, and in any case it's arguable that conn->status is slightly higher-level state, and thus not part of this function's purview.
2012-09-07 22:02:23 +02:00
/*
* pqDropConnection
*
* Close any physical connection to the server, and reset associated
* state inside the connection object. We don't release state that
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
* would be needed to reconnect, though, nor local state that might still
* be useful later.
Fix unwanted flushing of libpq's input buffer when socket EOF is seen. In commit 210eb9b743c0645d I centralized libpq's logic for closing down the backend communication socket, and made the new pqDropConnection routine always reset the I/O buffers to empty. Many of the call sites previously had not had such code, and while that amounted to an oversight in some cases, there was one place where it was intentional and necessary *not* to flush the input buffer: pqReadData should never cause that to happen, since we probably still want to process whatever data we read. This is the true cause of the problem Robert was attempting to fix in c3e7c24a1d60dc6a, namely that libpq no longer reported the backend's final ERROR message before reporting "server closed the connection unexpectedly". But that only accidentally fixed it, by invoking parseInput before the input buffer got flushed; and very likely there are timing scenarios where we'd still lose the message before processing it. To fix, pass a flag to pqDropConnection to tell it whether to flush the input buffer or not. On review I think flushing is actually correct for every other call site. Back-patch to 9.3 where the problem was introduced. In HEAD, also improve the comments added by c3e7c24a1d60dc6a.
2015-11-12 19:03:52 +01:00
*
* We can always flush the output buffer, since there's no longer any hope
* of sending that data. However, unprocessed input data might still be
* valuable, so the caller must tell us whether to flush that or not.
Centralize libpq's low-level code for dropping a connection. Create an internal function pqDropConnection that does the physical socket close and cleans up closely-associated state. This removes a bunch of ad hoc, not always consistent closure code. The ulterior motive is to have a single place to wait for a spawned child backend to exit, but this seems like good cleanup even if that never happens. I went back and forth on whether to include "conn->status = CONNECTION_BAD" in pqDropConnection's actions, but for the moment decided not to. Only a minority of the call sites actually want that, and in any case it's arguable that conn->status is slightly higher-level state, and thus not part of this function's purview.
2012-09-07 22:02:23 +02:00
*/
void
Fix unwanted flushing of libpq's input buffer when socket EOF is seen. In commit 210eb9b743c0645d I centralized libpq's logic for closing down the backend communication socket, and made the new pqDropConnection routine always reset the I/O buffers to empty. Many of the call sites previously had not had such code, and while that amounted to an oversight in some cases, there was one place where it was intentional and necessary *not* to flush the input buffer: pqReadData should never cause that to happen, since we probably still want to process whatever data we read. This is the true cause of the problem Robert was attempting to fix in c3e7c24a1d60dc6a, namely that libpq no longer reported the backend's final ERROR message before reporting "server closed the connection unexpectedly". But that only accidentally fixed it, by invoking parseInput before the input buffer got flushed; and very likely there are timing scenarios where we'd still lose the message before processing it. To fix, pass a flag to pqDropConnection to tell it whether to flush the input buffer or not. On review I think flushing is actually correct for every other call site. Back-patch to 9.3 where the problem was introduced. In HEAD, also improve the comments added by c3e7c24a1d60dc6a.
2015-11-12 19:03:52 +01:00
pqDropConnection(PGconn *conn, bool flushInput)
Centralize libpq's low-level code for dropping a connection. Create an internal function pqDropConnection that does the physical socket close and cleans up closely-associated state. This removes a bunch of ad hoc, not always consistent closure code. The ulterior motive is to have a single place to wait for a spawned child backend to exit, but this seems like good cleanup even if that never happens. I went back and forth on whether to include "conn->status = CONNECTION_BAD" in pqDropConnection's actions, but for the moment decided not to. Only a minority of the call sites actually want that, and in any case it's arguable that conn->status is slightly higher-level state, and thus not part of this function's purview.
2012-09-07 22:02:23 +02:00
{
/* Drop any SSL state */
pqsecure_close(conn);
Clear auth context correctly when re-connecting after failed auth attempt. If authentication over an SSL connection fails, with sslmode=prefer, libpq will reconnect without SSL and retry. However, we did not clear the variables related to GSS, SSPI, and SASL authentication state, when reconnecting. Because of that, the second authentication attempt would always fail with a "duplicate GSS/SASL authentication request" error. pg_SSPI_startup did not check for duplicate authentication requests like the corresponding GSS and SASL functions, so with SSPI, you would leak some memory instead. Another way this could manifest itself, on version 10, is if you list multiple hostnames in the "host" parameter. If the first server requests Kerberos or SCRAM authentication, but it fails, the attempts to connect to the other servers will also fail with "duplicate authentication request" errors. To fix, move the clearing of authentication state from closePGconn to pgDropConnection, so that it is cleared also when re-connecting. Patch by Michael Paquier, with some kibitzing by me. Backpatch down to 9.3. 9.2 has the same bug, but the code around closing the connection is somewhat different, so that this patch doesn't apply. To fix this in 9.2, I think we would need to back-port commit 210eb9b743 first, and then apply this patch. However, given that we only bumped into this in our own testing, we haven't heard any reports from users about this, and that 9.2 will be end-of-lifed in a couple of months anyway, it doesn't seem worth the risk and trouble. Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
Centralize libpq's low-level code for dropping a connection. Create an internal function pqDropConnection that does the physical socket close and cleans up closely-associated state. This removes a bunch of ad hoc, not always consistent closure code. The ulterior motive is to have a single place to wait for a spawned child backend to exit, but this seems like good cleanup even if that never happens. I went back and forth on whether to include "conn->status = CONNECTION_BAD" in pqDropConnection's actions, but for the moment decided not to. Only a minority of the call sites actually want that, and in any case it's arguable that conn->status is slightly higher-level state, and thus not part of this function's purview.
2012-09-07 22:02:23 +02:00
/* Close the socket itself */
libpq: use pgsocket for socket values, for portability Previously, 'int' was used for socket values in libpq, but socket values are unsigned on Windows. This is a style correction. Initial patch and previous PGINVALID_SOCKET initial patch by Joel Jacobson, modified by me Report from PVS-Studio
2014-04-17 01:46:51 +02:00
if (conn->sock != PGINVALID_SOCKET)
Centralize libpq's low-level code for dropping a connection. Create an internal function pqDropConnection that does the physical socket close and cleans up closely-associated state. This removes a bunch of ad hoc, not always consistent closure code. The ulterior motive is to have a single place to wait for a spawned child backend to exit, but this seems like good cleanup even if that never happens. I went back and forth on whether to include "conn->status = CONNECTION_BAD" in pqDropConnection's actions, but for the moment decided not to. Only a minority of the call sites actually want that, and in any case it's arguable that conn->status is slightly higher-level state, and thus not part of this function's purview.
2012-09-07 22:02:23 +02:00
closesocket(conn->sock);
libpq: use pgsocket for socket values, for portability Previously, 'int' was used for socket values in libpq, but socket values are unsigned on Windows. This is a style correction. Initial patch and previous PGINVALID_SOCKET initial patch by Joel Jacobson, modified by me Report from PVS-Studio
2014-04-17 01:46:51 +02:00
conn->sock = PGINVALID_SOCKET;
Clear auth context correctly when re-connecting after failed auth attempt. If authentication over an SSL connection fails, with sslmode=prefer, libpq will reconnect without SSL and retry. However, we did not clear the variables related to GSS, SSPI, and SASL authentication state, when reconnecting. Because of that, the second authentication attempt would always fail with a "duplicate GSS/SASL authentication request" error. pg_SSPI_startup did not check for duplicate authentication requests like the corresponding GSS and SASL functions, so with SSPI, you would leak some memory instead. Another way this could manifest itself, on version 10, is if you list multiple hostnames in the "host" parameter. If the first server requests Kerberos or SCRAM authentication, but it fails, the attempts to connect to the other servers will also fail with "duplicate authentication request" errors. To fix, move the clearing of authentication state from closePGconn to pgDropConnection, so that it is cleared also when re-connecting. Patch by Michael Paquier, with some kibitzing by me. Backpatch down to 9.3. 9.2 has the same bug, but the code around closing the connection is somewhat different, so that this patch doesn't apply. To fix this in 9.2, I think we would need to back-port commit 210eb9b743 first, and then apply this patch. However, given that we only bumped into this in our own testing, we haven't heard any reports from users about this, and that 9.2 will be end-of-lifed in a couple of months anyway, it doesn't seem worth the risk and trouble. Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
Fix unwanted flushing of libpq's input buffer when socket EOF is seen. In commit 210eb9b743c0645d I centralized libpq's logic for closing down the backend communication socket, and made the new pqDropConnection routine always reset the I/O buffers to empty. Many of the call sites previously had not had such code, and while that amounted to an oversight in some cases, there was one place where it was intentional and necessary *not* to flush the input buffer: pqReadData should never cause that to happen, since we probably still want to process whatever data we read. This is the true cause of the problem Robert was attempting to fix in c3e7c24a1d60dc6a, namely that libpq no longer reported the backend's final ERROR message before reporting "server closed the connection unexpectedly". But that only accidentally fixed it, by invoking parseInput before the input buffer got flushed; and very likely there are timing scenarios where we'd still lose the message before processing it. To fix, pass a flag to pqDropConnection to tell it whether to flush the input buffer or not. On review I think flushing is actually correct for every other call site. Back-patch to 9.3 where the problem was introduced. In HEAD, also improve the comments added by c3e7c24a1d60dc6a.
2015-11-12 19:03:52 +01:00
/* Optionally discard any unread data */
if (flushInput)
conn->inStart = conn->inCursor = conn->inEnd = 0;
Clear auth context correctly when re-connecting after failed auth attempt. If authentication over an SSL connection fails, with sslmode=prefer, libpq will reconnect without SSL and retry. However, we did not clear the variables related to GSS, SSPI, and SASL authentication state, when reconnecting. Because of that, the second authentication attempt would always fail with a "duplicate GSS/SASL authentication request" error. pg_SSPI_startup did not check for duplicate authentication requests like the corresponding GSS and SASL functions, so with SSPI, you would leak some memory instead. Another way this could manifest itself, on version 10, is if you list multiple hostnames in the "host" parameter. If the first server requests Kerberos or SCRAM authentication, but it fails, the attempts to connect to the other servers will also fail with "duplicate authentication request" errors. To fix, move the clearing of authentication state from closePGconn to pgDropConnection, so that it is cleared also when re-connecting. Patch by Michael Paquier, with some kibitzing by me. Backpatch down to 9.3. 9.2 has the same bug, but the code around closing the connection is somewhat different, so that this patch doesn't apply. To fix this in 9.2, I think we would need to back-port commit 210eb9b743 first, and then apply this patch. However, given that we only bumped into this in our own testing, we haven't heard any reports from users about this, and that 9.2 will be end-of-lifed in a couple of months anyway, it doesn't seem worth the risk and trouble. Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
Fix unwanted flushing of libpq's input buffer when socket EOF is seen. In commit 210eb9b743c0645d I centralized libpq's logic for closing down the backend communication socket, and made the new pqDropConnection routine always reset the I/O buffers to empty. Many of the call sites previously had not had such code, and while that amounted to an oversight in some cases, there was one place where it was intentional and necessary *not* to flush the input buffer: pqReadData should never cause that to happen, since we probably still want to process whatever data we read. This is the true cause of the problem Robert was attempting to fix in c3e7c24a1d60dc6a, namely that libpq no longer reported the backend's final ERROR message before reporting "server closed the connection unexpectedly". But that only accidentally fixed it, by invoking parseInput before the input buffer got flushed; and very likely there are timing scenarios where we'd still lose the message before processing it. To fix, pass a flag to pqDropConnection to tell it whether to flush the input buffer or not. On review I think flushing is actually correct for every other call site. Back-patch to 9.3 where the problem was introduced. In HEAD, also improve the comments added by c3e7c24a1d60dc6a.
2015-11-12 19:03:52 +01:00
/* Always discard any unsent data */
Centralize libpq's low-level code for dropping a connection. Create an internal function pqDropConnection that does the physical socket close and cleans up closely-associated state. This removes a bunch of ad hoc, not always consistent closure code. The ulterior motive is to have a single place to wait for a spawned child backend to exit, but this seems like good cleanup even if that never happens. I went back and forth on whether to include "conn->status = CONNECTION_BAD" in pqDropConnection's actions, but for the moment decided not to. Only a minority of the call sites actually want that, and in any case it's arguable that conn->status is slightly higher-level state, and thus not part of this function's purview.
2012-09-07 22:02:23 +02:00
conn->outCount = 0;
Clear auth context correctly when re-connecting after failed auth attempt. If authentication over an SSL connection fails, with sslmode=prefer, libpq will reconnect without SSL and retry. However, we did not clear the variables related to GSS, SSPI, and SASL authentication state, when reconnecting. Because of that, the second authentication attempt would always fail with a "duplicate GSS/SASL authentication request" error. pg_SSPI_startup did not check for duplicate authentication requests like the corresponding GSS and SASL functions, so with SSPI, you would leak some memory instead. Another way this could manifest itself, on version 10, is if you list multiple hostnames in the "host" parameter. If the first server requests Kerberos or SCRAM authentication, but it fails, the attempts to connect to the other servers will also fail with "duplicate authentication request" errors. To fix, move the clearing of authentication state from closePGconn to pgDropConnection, so that it is cleared also when re-connecting. Patch by Michael Paquier, with some kibitzing by me. Backpatch down to 9.3. 9.2 has the same bug, but the code around closing the connection is somewhat different, so that this patch doesn't apply. To fix this in 9.2, I think we would need to back-port commit 210eb9b743 first, and then apply this patch. However, given that we only bumped into this in our own testing, we haven't heard any reports from users about this, and that 9.2 will be end-of-lifed in a couple of months anyway, it doesn't seem worth the risk and trouble. Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
libpq: drop pending pipelined commands in pqDropConnection(). The original coding did this in pqDropServerData(), which seems fairly backwards. Pending commands are more like already-queued output data, which is dropped in pqDropConnection(). Moving the operation means that we clear the command queue immediately upon detecting connection drop, which improves the sanity of subsequent behavior. In particular this eliminates duplicated error message text as a consequence of code added in b15f25446, which supposed that a nonempty command queue must mean the prior operation is still active. There might be an argument for backpatching this to v14; but as with b15f25446, I'm unsure about interactions with 618c16707. For now, given the lack of complaints about v14's behavior, leave it alone. Per report from Peter Eisentraut. Discussion: https://postgr.es/m/de57761c-b99b-3435-b0a6-474c72b1149a@enterprisedb.com
2022-05-12 18:42:29 +02:00
/* Likewise, discard any pending pipelined commands */
pqFreeCommandQueue(conn->cmd_queue_head);
conn->cmd_queue_head = conn->cmd_queue_tail = NULL;
pqFreeCommandQueue(conn->cmd_queue_recycle);
conn->cmd_queue_recycle = NULL;
Extensive code review for GSSAPI encryption mechanism. Fix assorted bugs in handling of non-blocking I/O when using GSSAPI encryption. The encryption layer could return the wrong status information to its caller, resulting in effectively dropping some data (or possibly in aborting a not-broken connection), or in a "livelock" situation where data remains to be sent but the upper layers think transmission is done and just go to sleep. There were multiple small thinkos contributing to that, as well as one big one (failure to think through what to do when a send fails after having already transmitted data). Note that these errors could cause failures whether the client application asked for non-blocking I/O or not, since both libpq and the backend always run things in non-block mode at this level. Also get rid of use of static variables for GSSAPI inside libpq; that's entirely not okay given that multiple connections could be open at once inside a single client process. Also adjust a bunch of random small discrepancies between the frontend and backend versions of the send/receive functions -- except for error handling, they should be identical, and now they are. Also extend the Kerberos TAP tests to exercise cases where nontrivial amounts of data need to be pushed through encryption. Before, those tests didn't provide any useful coverage at all for the cases of interest here. (They still might not, depending on timing, but at least there's a chance.) Per complaint from pmc@citylink and subsequent investigation. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/20200109181822.GA74698@gate.oper.dinoex.org
2020-01-11 23:14:08 +01:00
/* Free authentication/encryption state */
Clear auth context correctly when re-connecting after failed auth attempt. If authentication over an SSL connection fails, with sslmode=prefer, libpq will reconnect without SSL and retry. However, we did not clear the variables related to GSS, SSPI, and SASL authentication state, when reconnecting. Because of that, the second authentication attempt would always fail with a "duplicate GSS/SASL authentication request" error. pg_SSPI_startup did not check for duplicate authentication requests like the corresponding GSS and SASL functions, so with SSPI, you would leak some memory instead. Another way this could manifest itself, on version 10, is if you list multiple hostnames in the "host" parameter. If the first server requests Kerberos or SCRAM authentication, but it fails, the attempts to connect to the other servers will also fail with "duplicate authentication request" errors. To fix, move the clearing of authentication state from closePGconn to pgDropConnection, so that it is cleared also when re-connecting. Patch by Michael Paquier, with some kibitzing by me. Backpatch down to 9.3. 9.2 has the same bug, but the code around closing the connection is somewhat different, so that this patch doesn't apply. To fix this in 9.2, I think we would need to back-port commit 210eb9b743 first, and then apply this patch. However, given that we only bumped into this in our own testing, we haven't heard any reports from users about this, and that 9.2 will be end-of-lifed in a couple of months anyway, it doesn't seem worth the risk and trouble. Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
#ifdef ENABLE_GSS
{
OM_uint32 min_s;
Fix bugs in libpq's management of GSS encryption state. GSS-related resources should be cleaned up in pqDropConnection, not freePGconn, else the wrong things happen when resetting a connection or trying to switch to a different server. It's also critical to reset conn->gssenc there. During connection setup, initialize conn->try_gss at the correct place, else switching to a different server won't work right. Remove now-redundant cleanup of GSS resources around one (and, for some reason, only one) pqDropConnection call in connectDBStart. Per report from Kyotaro Horiguchi that psql would freeze up, rather than successfully resetting a GSS-encrypted connection after a server restart. This is YA oversight in commit b0b39f72b, so back-patch to v12. Discussion: https://postgr.es/m/20200710.173803.435804731896516388.horikyota.ntt@gmail.com
2020-07-13 17:57:55 +02:00
if (conn->gcred != GSS_C_NO_CREDENTIAL)
{
gss_release_cred(&min_s, &conn->gcred);
conn->gcred = GSS_C_NO_CREDENTIAL;
}
Clear auth context correctly when re-connecting after failed auth attempt. If authentication over an SSL connection fails, with sslmode=prefer, libpq will reconnect without SSL and retry. However, we did not clear the variables related to GSS, SSPI, and SASL authentication state, when reconnecting. Because of that, the second authentication attempt would always fail with a "duplicate GSS/SASL authentication request" error. pg_SSPI_startup did not check for duplicate authentication requests like the corresponding GSS and SASL functions, so with SSPI, you would leak some memory instead. Another way this could manifest itself, on version 10, is if you list multiple hostnames in the "host" parameter. If the first server requests Kerberos or SCRAM authentication, but it fails, the attempts to connect to the other servers will also fail with "duplicate authentication request" errors. To fix, move the clearing of authentication state from closePGconn to pgDropConnection, so that it is cleared also when re-connecting. Patch by Michael Paquier, with some kibitzing by me. Backpatch down to 9.3. 9.2 has the same bug, but the code around closing the connection is somewhat different, so that this patch doesn't apply. To fix this in 9.2, I think we would need to back-port commit 210eb9b743 first, and then apply this patch. However, given that we only bumped into this in our own testing, we haven't heard any reports from users about this, and that 9.2 will be end-of-lifed in a couple of months anyway, it doesn't seem worth the risk and trouble. Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
if (conn->gctx)
gss_delete_sec_context(&min_s, &conn->gctx, GSS_C_NO_BUFFER);
if (conn->gtarg_nam)
gss_release_name(&min_s, &conn->gtarg_nam);
Extensive code review for GSSAPI encryption mechanism. Fix assorted bugs in handling of non-blocking I/O when using GSSAPI encryption. The encryption layer could return the wrong status information to its caller, resulting in effectively dropping some data (or possibly in aborting a not-broken connection), or in a "livelock" situation where data remains to be sent but the upper layers think transmission is done and just go to sleep. There were multiple small thinkos contributing to that, as well as one big one (failure to think through what to do when a send fails after having already transmitted data). Note that these errors could cause failures whether the client application asked for non-blocking I/O or not, since both libpq and the backend always run things in non-block mode at this level. Also get rid of use of static variables for GSSAPI inside libpq; that's entirely not okay given that multiple connections could be open at once inside a single client process. Also adjust a bunch of random small discrepancies between the frontend and backend versions of the send/receive functions -- except for error handling, they should be identical, and now they are. Also extend the Kerberos TAP tests to exercise cases where nontrivial amounts of data need to be pushed through encryption. Before, those tests didn't provide any useful coverage at all for the cases of interest here. (They still might not, depending on timing, but at least there's a chance.) Per complaint from pmc@citylink and subsequent investigation. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/20200109181822.GA74698@gate.oper.dinoex.org
2020-01-11 23:14:08 +01:00
if (conn->gss_SendBuffer)
{
free(conn->gss_SendBuffer);
conn->gss_SendBuffer = NULL;
}
if (conn->gss_RecvBuffer)
{
free(conn->gss_RecvBuffer);
conn->gss_RecvBuffer = NULL;
}
if (conn->gss_ResultBuffer)
{
free(conn->gss_ResultBuffer);
conn->gss_ResultBuffer = NULL;
}
Fix bugs in libpq's management of GSS encryption state. GSS-related resources should be cleaned up in pqDropConnection, not freePGconn, else the wrong things happen when resetting a connection or trying to switch to a different server. It's also critical to reset conn->gssenc there. During connection setup, initialize conn->try_gss at the correct place, else switching to a different server won't work right. Remove now-redundant cleanup of GSS resources around one (and, for some reason, only one) pqDropConnection call in connectDBStart. Per report from Kyotaro Horiguchi that psql would freeze up, rather than successfully resetting a GSS-encrypted connection after a server restart. This is YA oversight in commit b0b39f72b, so back-patch to v12. Discussion: https://postgr.es/m/20200710.173803.435804731896516388.horikyota.ntt@gmail.com
2020-07-13 17:57:55 +02:00
conn->gssenc = false;
Clear auth context correctly when re-connecting after failed auth attempt. If authentication over an SSL connection fails, with sslmode=prefer, libpq will reconnect without SSL and retry. However, we did not clear the variables related to GSS, SSPI, and SASL authentication state, when reconnecting. Because of that, the second authentication attempt would always fail with a "duplicate GSS/SASL authentication request" error. pg_SSPI_startup did not check for duplicate authentication requests like the corresponding GSS and SASL functions, so with SSPI, you would leak some memory instead. Another way this could manifest itself, on version 10, is if you list multiple hostnames in the "host" parameter. If the first server requests Kerberos or SCRAM authentication, but it fails, the attempts to connect to the other servers will also fail with "duplicate authentication request" errors. To fix, move the clearing of authentication state from closePGconn to pgDropConnection, so that it is cleared also when re-connecting. Patch by Michael Paquier, with some kibitzing by me. Backpatch down to 9.3. 9.2 has the same bug, but the code around closing the connection is somewhat different, so that this patch doesn't apply. To fix this in 9.2, I think we would need to back-port commit 210eb9b743 first, and then apply this patch. However, given that we only bumped into this in our own testing, we haven't heard any reports from users about this, and that 9.2 will be end-of-lifed in a couple of months anyway, it doesn't seem worth the risk and trouble. Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
}
#endif
#ifdef ENABLE_SSPI
if (conn->sspitarget)
{
free(conn->sspitarget);
conn->sspitarget = NULL;
}
if (conn->sspicred)
{
FreeCredentialsHandle(conn->sspicred);
free(conn->sspicred);
conn->sspicred = NULL;
}
if (conn->sspictx)
{
DeleteSecurityContext(conn->sspictx);
free(conn->sspictx);
conn->sspictx = NULL;
}
conn->usesspi = 0;
#endif
if (conn->sasl_state)
{
Refactor SASL code with a generic interface for its mechanisms The code of SCRAM and SASL have been tightly linked together since SCRAM exists in the core code, making hard to apprehend the addition of new SASL mechanisms, but these are by design different facilities, with SCRAM being an option for SASL. This refactors the code related to both so as the backend and the frontend use a set of callbacks for SASL mechanisms, documenting while on it what is expected by anybody adding a new SASL mechanism. The separation between both layers is neat, using two sets of callbacks for the frontend and the backend to mark the frontier between both facilities. The shape of the callbacks is now directly inspired from the routines used by SCRAM, so the code change is straight-forward, and the SASL code is moved into its own set of files. These will likely change depending on how and if new SASL mechanisms get added in the future. Author: Jacob Champion Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/3d2a6f5d50e741117d6baf83eb67ebf1a8a35a11.camel@vmware.com
2021-07-07 03:55:15 +02:00
conn->sasl->free(conn->sasl_state);
Clear auth context correctly when re-connecting after failed auth attempt. If authentication over an SSL connection fails, with sslmode=prefer, libpq will reconnect without SSL and retry. However, we did not clear the variables related to GSS, SSPI, and SASL authentication state, when reconnecting. Because of that, the second authentication attempt would always fail with a "duplicate GSS/SASL authentication request" error. pg_SSPI_startup did not check for duplicate authentication requests like the corresponding GSS and SASL functions, so with SSPI, you would leak some memory instead. Another way this could manifest itself, on version 10, is if you list multiple hostnames in the "host" parameter. If the first server requests Kerberos or SCRAM authentication, but it fails, the attempts to connect to the other servers will also fail with "duplicate authentication request" errors. To fix, move the clearing of authentication state from closePGconn to pgDropConnection, so that it is cleared also when re-connecting. Patch by Michael Paquier, with some kibitzing by me. Backpatch down to 9.3. 9.2 has the same bug, but the code around closing the connection is somewhat different, so that this patch doesn't apply. To fix this in 9.2, I think we would need to back-port commit 210eb9b743 first, and then apply this patch. However, given that we only bumped into this in our own testing, we haven't heard any reports from users about this, and that 9.2 will be end-of-lifed in a couple of months anyway, it doesn't seem worth the risk and trouble. Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
conn->sasl_state = NULL;
}
Centralize libpq's low-level code for dropping a connection. Create an internal function pqDropConnection that does the physical socket close and cleans up closely-associated state. This removes a bunch of ad hoc, not always consistent closure code. The ulterior motive is to have a single place to wait for a spawned child backend to exit, but this seems like good cleanup even if that never happens. I went back and forth on whether to include "conn->status = CONNECTION_BAD" in pqDropConnection's actions, but for the moment decided not to. Only a minority of the call sites actually want that, and in any case it's arguable that conn->status is slightly higher-level state, and thus not part of this function's purview.
2012-09-07 22:02:23 +02:00
}
Implement pipeline mode in libpq Pipeline mode in libpq lets an application avoid the Sync messages in the FE/BE protocol that are implicit in the old libpq API after each query. The application can then insert Sync at its leisure with a new libpq function PQpipelineSync. This can lead to substantial reductions in query latency. Co-authored-by: Craig Ringer <craig.ringer@enterprisedb.com> Co-authored-by: Matthieu Garrigues <matthieu.garrigues@gmail.com> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Aya Iwata <iwata.aya@jp.fujitsu.com> Reviewed-by: Daniel Vérité <daniel@manitou-mail.org> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Kirk Jamison <k.jamison@fujitsu.com> Reviewed-by: Michael Paquier <michael.paquier@gmail.com> Reviewed-by: Nikhil Sontakke <nikhils@2ndquadrant.com> Reviewed-by: Vaishnavi Prabakaran <VaishnaviP@fast.au.fujitsu.com> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Discussion: https://postgr.es/m/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com Discussion: https://postgr.es/m/CAJkzx4T5E-2cQe3dtv2R78dYFvz+in8PY7A8MArvLhs_pg75gg@mail.gmail.com
2021-03-15 22:13:42 +01:00
/*
* pqFreeCommandQueue
* Free all the entries of PGcmdQueueEntry queue passed.
*/
static void
pqFreeCommandQueue(PGcmdQueueEntry *queue)
{
while (queue != NULL)
{
PGcmdQueueEntry *cur = queue;
queue = cur->next;
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(cur->query);
Implement pipeline mode in libpq Pipeline mode in libpq lets an application avoid the Sync messages in the FE/BE protocol that are implicit in the old libpq API after each query. The application can then insert Sync at its leisure with a new libpq function PQpipelineSync. This can lead to substantial reductions in query latency. Co-authored-by: Craig Ringer <craig.ringer@enterprisedb.com> Co-authored-by: Matthieu Garrigues <matthieu.garrigues@gmail.com> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Aya Iwata <iwata.aya@jp.fujitsu.com> Reviewed-by: Daniel Vérité <daniel@manitou-mail.org> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Kirk Jamison <k.jamison@fujitsu.com> Reviewed-by: Michael Paquier <michael.paquier@gmail.com> Reviewed-by: Nikhil Sontakke <nikhils@2ndquadrant.com> Reviewed-by: Vaishnavi Prabakaran <VaishnaviP@fast.au.fujitsu.com> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Discussion: https://postgr.es/m/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com Discussion: https://postgr.es/m/CAJkzx4T5E-2cQe3dtv2R78dYFvz+in8PY7A8MArvLhs_pg75gg@mail.gmail.com
2021-03-15 22:13:42 +01:00
free(cur);
}
}
Centralize libpq's low-level code for dropping a connection. Create an internal function pqDropConnection that does the physical socket close and cleans up closely-associated state. This removes a bunch of ad hoc, not always consistent closure code. The ulterior motive is to have a single place to wait for a spawned child backend to exit, but this seems like good cleanup even if that never happens. I went back and forth on whether to include "conn->status = CONNECTION_BAD" in pqDropConnection's actions, but for the moment decided not to. Only a minority of the call sites actually want that, and in any case it's arguable that conn->status is slightly higher-level state, and thus not part of this function's purview.
2012-09-07 22:02:23 +02:00
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/*
* pqDropServerData
*
* Clear all connection state data that was received from (or deduced about)
* the server. This is essential to do between connection attempts to
* different servers, else we may incorrectly hold over some data from the
* old server.
*
* It would be better to merge this into pqDropConnection, perhaps, but
* right now we cannot because that function is called immediately on
* detection of connection loss (cf. pqReadData, for instance). This data
* should be kept until we are actually starting a new connection.
*/
static void
pqDropServerData(PGconn *conn)
{
PGnotify *notify;
pgParameterStatus *pstatus;
/* Forget pending notifies */
notify = conn->notifyHead;
while (notify != NULL)
{
PGnotify *prev = notify;
notify = notify->next;
free(prev);
}
conn->notifyHead = conn->notifyTail = NULL;
/* Reset ParameterStatus data, as well as variables deduced from it */
pstatus = conn->pstatus;
while (pstatus != NULL)
{
pgParameterStatus *prev = pstatus;
pstatus = pstatus->next;
free(prev);
}
conn->pstatus = NULL;
conn->client_encoding = PG_SQL_ASCII;
conn->std_strings = false;
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
conn->default_transaction_read_only = PG_BOOL_UNKNOWN;
conn->in_hot_standby = PG_BOOL_UNKNOWN;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->sversion = 0;
/* Drop large-object lookup data */
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->lobjfuncs);
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->lobjfuncs = NULL;
/* Reset assorted other per-connection state */
conn->last_sqlstate[0] = '\0';
conn->auth_req_received = false;
conn->password_needed = false;
Restructure libpq's handling of send failures. Originally, if libpq got a failure (e.g., ECONNRESET) while trying to send data to the server, it would just report that and wash its hands of the matter. It was soon found that that wasn't a very pleasant way of coping with server-initiated disconnections, so we introduced a hack (pqHandleSendFailure) in the code that sends queries to make it peek ahead for server error reports before reporting the send failure. It now emerges that related cases can occur during connection setup; in particular, as of TLS 1.3 it's unsafe to assume that SSL connection failures will be reported by SSL_connect rather than during our first send attempt. We could have fixed that in a hacky way by applying pqHandleSendFailure after a startup packet send failure, but (a) pqHandleSendFailure explicitly disclaims suitability for use in any state except query startup, and (b) the problem still potentially exists for other send attempts in libpq. Instead, let's fix this in a more general fashion by eliminating pqHandleSendFailure altogether, and instead arranging to postpone all reports of send failures in libpq until after we've made an attempt to read and process server messages. The send failure won't be reported at all if we find a server message or detect input EOF. (Note: this removes one of the reasons why libpq typically overwrites, rather than appending to, conn->errorMessage: pqHandleSendFailure needed that behavior so that the send failure report would be replaced if we got a server message or read failure report. Eventually I'd like to get rid of that overwrite behavior altogether, but today is not that day. For the moment, pqSendSome is assuming that its callees will overwrite not append to conn->errorMessage.) Possibly this change should get back-patched someday; but it needs testing first, so let's not consider that till after v12 beta. Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
conn->write_failed = false;
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->write_err_msg);
Restructure libpq's handling of send failures. Originally, if libpq got a failure (e.g., ECONNRESET) while trying to send data to the server, it would just report that and wash its hands of the matter. It was soon found that that wasn't a very pleasant way of coping with server-initiated disconnections, so we introduced a hack (pqHandleSendFailure) in the code that sends queries to make it peek ahead for server error reports before reporting the send failure. It now emerges that related cases can occur during connection setup; in particular, as of TLS 1.3 it's unsafe to assume that SSL connection failures will be reported by SSL_connect rather than during our first send attempt. We could have fixed that in a hacky way by applying pqHandleSendFailure after a startup packet send failure, but (a) pqHandleSendFailure explicitly disclaims suitability for use in any state except query startup, and (b) the problem still potentially exists for other send attempts in libpq. Instead, let's fix this in a more general fashion by eliminating pqHandleSendFailure altogether, and instead arranging to postpone all reports of send failures in libpq until after we've made an attempt to read and process server messages. The send failure won't be reported at all if we find a server message or detect input EOF. (Note: this removes one of the reasons why libpq typically overwrites, rather than appending to, conn->errorMessage: pqHandleSendFailure needed that behavior so that the send failure report would be replaced if we got a server message or read failure report. Eventually I'd like to get rid of that overwrite behavior altogether, but today is not that day. For the moment, pqSendSome is assuming that its callees will overwrite not append to conn->errorMessage.) Possibly this change should get back-patched someday; but it needs testing first, so let's not consider that till after v12 beta. Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
conn->write_err_msg = NULL;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->be_pid = 0;
conn->be_key = 0;
}
Remove some unneeded dashes from libpq comments.
2001-08-17 17:11:15 +02:00
/*
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* Connecting to a Database
*
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
* There are now six different ways a user of this API can connect to the
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* database. Two are not recommended for use in new code, because of their
* lack of extensibility with respect to the passing of options to the
* backend. These are PQsetdb and PQsetdbLogin (the former now being a macro
* to the latter).
*
* If it is desired to connect in a synchronous (blocking) manner, use the
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
* function PQconnectdb or PQconnectdbParams. The former accepts a string of
* option = value pairs (or a URI) which must be parsed; the latter takes two
* NULL terminated arrays instead.
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
*
This patch fixes a bunch of spelling mistakes in comments throughout the PostgreSQL source code. Neil Conway
2003-03-10 23:28:22 +01:00
* To connect in an asynchronous (non-blocking) manner, use the functions
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
* PQconnectStart or PQconnectStartParams (which differ in the same way as
* PQconnectdb and PQconnectdbParams) and PQconnectPoll.
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
*
* Internally, the static functions connectDBStart, connectDBComplete
* are part of the connection procedure.
*/
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
/*
* PQconnectdbParams
*
* establishes a connection to a postgres backend through the postmaster
* using connection information in two arrays.
*
* The keywords array is defined as
*
* const char *params[] = {"option1", "option2", NULL}
*
* The values array is defined as
*
* const char *values[] = {"value1", "value2", NULL}
*
* Returns a PGconn* which is needed for all subsequent libpq calls, or NULL
* if a memory allocation failed.
* If the status field of the connection returned is CONNECTION_BAD,
* then some fields may be null'ed out instead of having valid values.
*
* You should call PQfinish (if conn is not NULL) regardless of whether this
* call succeeded.
*/
PGconn *
Fully const-ify PQconnectdbParams, PQconnectStartParams, and PQpingParams. The keywords and values arguments of these functions are more properly declared "const char * const *" than just "const char **". Lionel Elie Mamane, reviewed by Craig Ringer
2011-09-26 00:52:48 +02:00
PQconnectdbParams(const char *const *keywords,
const char *const *values,
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
int expand_dbname)
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
{
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
PGconn *conn = PQconnectStartParams(keywords, values, expand_dbname);
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
if (conn && conn->status != CONNECTION_BAD)
(void) connectDBComplete(conn);
return conn;
}
Rewrite PQping to be more like what we agreed to last week. Basically, we want to distinguish all cases where the connection was not made from those where it was. A convenient proxy for this is to see if we got a message with a SQLSTATE code back from the postmaster. This presumes that the postmaster will always send us a SQLSTATE in a failure message, which is true for 7.4 and later postmasters in every case except fork failure. (We could possibly complicate the postmaster code to do something about that, but it seems not worth the trouble, especially since pg_ctl's response for that case should be to keep waiting anyway.) If we did get a SQLSTATE from the postmaster, there are basically only two cases, as per last week's discussion: ERRCODE_CANNOT_CONNECT_NOW and everything else. Any other error code implies that the postmaster is in principle willing to accept connections, it just didn't like or couldn't handle this particular request. We want to make a special case for ERRCODE_CANNOT_CONNECT_NOW so that "pg_ctl start -w" knows it should keep waiting. In passing, pick names for the enum constants that are a tad less likely to present collision hazards in future.
2010-11-27 07:30:34 +01:00
/*
* PQpingParams
*
* check server status, accepting parameters identical to PQconnectdbParams
*/
Add PQping and PQpingParams to libpq to allow detection of the server's status, including a status where the server is running but refuses a postgres connection. Have pg_ctl use this new function. This fixes the case where pg_ctl reports that the server is not running (cannot connect) but in fact it is running.
2010-11-25 19:09:38 +01:00
PGPing
Fully const-ify PQconnectdbParams, PQconnectStartParams, and PQpingParams. The keywords and values arguments of these functions are more properly declared "const char * const *" than just "const char **". Lionel Elie Mamane, reviewed by Craig Ringer
2011-09-26 00:52:48 +02:00
PQpingParams(const char *const *keywords,
const char *const *values,
Rewrite PQping to be more like what we agreed to last week. Basically, we want to distinguish all cases where the connection was not made from those where it was. A convenient proxy for this is to see if we got a message with a SQLSTATE code back from the postmaster. This presumes that the postmaster will always send us a SQLSTATE in a failure message, which is true for 7.4 and later postmasters in every case except fork failure. (We could possibly complicate the postmaster code to do something about that, but it seems not worth the trouble, especially since pg_ctl's response for that case should be to keep waiting anyway.) If we did get a SQLSTATE from the postmaster, there are basically only two cases, as per last week's discussion: ERRCODE_CANNOT_CONNECT_NOW and everything else. Any other error code implies that the postmaster is in principle willing to accept connections, it just didn't like or couldn't handle this particular request. We want to make a special case for ERRCODE_CANNOT_CONNECT_NOW so that "pg_ctl start -w" knows it should keep waiting. In passing, pick names for the enum constants that are a tad less likely to present collision hazards in future.
2010-11-27 07:30:34 +01:00
int expand_dbname)
Add PQping and PQpingParams to libpq to allow detection of the server's status, including a status where the server is running but refuses a postgres connection. Have pg_ctl use this new function. This fixes the case where pg_ctl reports that the server is not running (cannot connect) but in fact it is running.
2010-11-25 19:09:38 +01:00
{
PGconn *conn = PQconnectStartParams(keywords, values, expand_dbname);
PGPing ret;
ret = internal_ping(conn);
PQfinish(conn);
return ret;
}
Remove some unneeded dashes from libpq comments.
2001-08-17 17:11:15 +02:00
/*
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
* PQconnectdb
*
Add PGTZ environment variable to initialization code. Rename PG_DATESTYLE to PGDATESTYLE environment variable. Move environment variable code to a different place so it now works! Note that regression tests can now run with "setenv PGTZ PST8PDT" at the frontend rather than requiring the backend to have TZ set.
1997-11-10 16:41:58 +01:00
* establishes a connection to a postgres backend through the postmaster
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
* using connection information in a string.
*
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
* The conninfo string is either a whitespace-separated list of
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*
* option = value
*
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
* definitions or a URI (refer to the documentation for details.) Value
* might be a single value containing no whitespaces or a single quoted
* string. If a single quote should appear anywhere in the value, it must be
* escaped with a backslash like \'
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* Returns a PGconn* which is needed for all subsequent libpq calls, or NULL
* if a memory allocation failed.
* If the status field of the connection returned is CONNECTION_BAD,
* then some fields may be null'ed out instead of having valid values.
*
* You should call PQfinish (if conn is not NULL) regardless of whether this
* call succeeded.
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
*/
Add PGTZ environment variable to initialization code. Rename PG_DATESTYLE to PGDATESTYLE environment variable. Move environment variable code to a different place so it now works! Note that regression tests can now run with "setenv PGTZ PST8PDT" at the frontend rather than requiring the backend to have TZ set.
1997-11-10 16:41:58 +01:00
PGconn *
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
PQconnectdb(const char *conninfo)
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
{
PGconn *conn = PQconnectStart(conninfo);
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
if (conn && conn->status != CONNECTION_BAD)
(void) connectDBComplete(conn);
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
return conn;
}
Rewrite PQping to be more like what we agreed to last week. Basically, we want to distinguish all cases where the connection was not made from those where it was. A convenient proxy for this is to see if we got a message with a SQLSTATE code back from the postmaster. This presumes that the postmaster will always send us a SQLSTATE in a failure message, which is true for 7.4 and later postmasters in every case except fork failure. (We could possibly complicate the postmaster code to do something about that, but it seems not worth the trouble, especially since pg_ctl's response for that case should be to keep waiting anyway.) If we did get a SQLSTATE from the postmaster, there are basically only two cases, as per last week's discussion: ERRCODE_CANNOT_CONNECT_NOW and everything else. Any other error code implies that the postmaster is in principle willing to accept connections, it just didn't like or couldn't handle this particular request. We want to make a special case for ERRCODE_CANNOT_CONNECT_NOW so that "pg_ctl start -w" knows it should keep waiting. In passing, pick names for the enum constants that are a tad less likely to present collision hazards in future.
2010-11-27 07:30:34 +01:00
/*
* PQping
*
* check server status, accepting parameters identical to PQconnectdb
*/
Add PQping and PQpingParams to libpq to allow detection of the server's status, including a status where the server is running but refuses a postgres connection. Have pg_ctl use this new function. This fixes the case where pg_ctl reports that the server is not running (cannot connect) but in fact it is running.
2010-11-25 19:09:38 +01:00
PGPing
PQping(const char *conninfo)
{
PGconn *conn = PQconnectStart(conninfo);
PGPing ret;
ret = internal_ping(conn);
PQfinish(conn);
return ret;
}
Remove some unneeded dashes from libpq comments.
2001-08-17 17:11:15 +02:00
/*
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
* PQconnectStartParams
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
*
* Begins the establishment of a connection to a postgres backend through the
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
* postmaster using connection information in a struct.
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
*
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
* See comment for PQconnectdbParams for the definition of the string format.
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
*
* Returns a PGconn*. If NULL is returned, a malloc error has occurred, and
* you should not attempt to proceed with this connection. If the status
* field of the connection returned is CONNECTION_BAD, an error has
* occurred. In this case you should call PQfinish on the result, (perhaps
* inspecting the error message first). Other fields of the structure may not
* be valid if that occurs. If the status field is not CONNECTION_BAD, then
* this stage has succeeded - call PQconnectPoll, using select(2) to see when
* this is necessary.
*
* See PQconnectPoll for more info.
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
*/
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
PGconn *
Fully const-ify PQconnectdbParams, PQconnectStartParams, and PQpingParams. The keywords and values arguments of these functions are more properly declared "const char * const *" than just "const char **". Lionel Elie Mamane, reviewed by Craig Ringer
2011-09-26 00:52:48 +02:00
PQconnectStartParams(const char *const *keywords,
const char *const *values,
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
int expand_dbname)
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
PGconn *conn;
PQconninfoOption *connOptions;
pgindent run before 6.3 release, with Thomas' requested changes.
1998-02-26 05:46:47 +01:00
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
/*
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
* Allocate memory for the conn structure. Note that we also expect this
* to initialize conn->errorMessage to empty. All subsequent steps during
* connection initialization will only append to that buffer.
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*/
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
conn = makeEmptyPGconn();
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
if (conn == NULL)
More janitorial work: remove the explicit casting of NULL literals to a pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
2004-01-07 19:56:30 +01:00
return NULL;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
/*
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
* Parse the conninfo arrays
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
*/
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
connOptions = conninfo_array_parse(keywords, values,
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
&conn->errorMessage,
true, expand_dbname);
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
if (connOptions == NULL)
{
conn->status = CONNECTION_BAD;
/* errorMessage is already set */
Fix typo in PQconnectStartParams(). This would lead to leaking the PGconn structure after an error detected by conninfo_array_parse(), as well as failing to return a useful error message in such cases. Backpatch to 9.0 where the error was introduced. Joseph Adams
2011-04-03 00:05:42 +02:00
return conn;
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
}
/*
* Move option values into conn structure
*/
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!fillPGconn(conn, connOptions))
{
PQconninfoFree(connOptions);
return conn;
}
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
/*
* Free the option info - all is in conn now
*/
PQconninfoFree(connOptions);
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
/*
* Compute derived options
*/
if (!connectOptions2(conn))
return conn;
/*
* Connect to the database
*/
if (!connectDBStart(conn))
{
/* Just in case we failed to set it in connectDBStart */
conn->status = CONNECTION_BAD;
}
return conn;
}
/*
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
* PQconnectStart
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
*
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
* Begins the establishment of a connection to a postgres backend through the
* postmaster using connection information in a string.
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
*
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
* See comment for PQconnectdb for the definition of the string format.
*
* Returns a PGconn*. If NULL is returned, a malloc error has occurred, and
* you should not attempt to proceed with this connection. If the status
* field of the connection returned is CONNECTION_BAD, an error has
* occurred. In this case you should call PQfinish on the result, (perhaps
* inspecting the error message first). Other fields of the structure may not
* be valid if that occurs. If the status field is not CONNECTION_BAD, then
* this stage has succeeded - call PQconnectPoll, using select(2) to see when
* this is necessary.
*
* See PQconnectPoll for more info.
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
*/
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
PGconn *
PQconnectStart(const char *conninfo)
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
{
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
PGconn *conn;
/*
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
* Allocate memory for the conn structure. Note that we also expect this
* to initialize conn->errorMessage to empty. All subsequent steps during
* connection initialization will only append to that buffer.
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
*/
conn = makeEmptyPGconn();
if (conn == NULL)
return NULL;
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
/*
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
* Parse the conninfo string
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*/
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
if (!connectOptions1(conn, conninfo))
return conn;
/*
* Compute derived options
*/
if (!connectOptions2(conn))
return conn;
/*
* Connect to the database
*/
if (!connectDBStart(conn))
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
/* Just in case we failed to set it in connectDBStart */
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
conn->status = CONNECTION_BAD;
}
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
return conn;
}
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
/*
* Move option values into conn structure
*
* Don't put anything cute here --- intelligence should be in
* connectOptions2 ...
*
* Returns true on success. On failure, returns false and sets error message.
*/
static bool
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
fillPGconn(PGconn *conn, PQconninfoOption *connOptions)
{
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
const internalPQconninfoOption *option;
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
for (option = PQconninfoOptions; option->keyword; option++)
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
{
Fix minor bugs in commit 30bf4689a96cd283af33edcdd6b7210df3f20cd8 et al. Coverity complained that the "else" added to fillPGconn() was unreachable, which it was. Remove the dead code. In passing, rearrange the tests so as not to bother trying to fetch values for options that can't be assigned. Pre-9.3 did not have that issue, but it did have a "return" that should be "goto oom_error" to ensure that a suitable error message gets filled in.
2014-11-30 18:20:44 +01:00
if (option->connofs >= 0)
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
{
Fix minor bugs in commit 30bf4689a96cd283af33edcdd6b7210df3f20cd8 et al. Coverity complained that the "else" added to fillPGconn() was unreachable, which it was. Remove the dead code. In passing, rearrange the tests so as not to bother trying to fetch values for options that can't be assigned. Pre-9.3 did not have that issue, but it did have a "return" that should be "goto oom_error" to ensure that a suitable error message gets filled in.
2014-11-30 18:20:44 +01:00
const char *tmp = conninfo_getval(connOptions, option->keyword);
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (tmp)
{
Fix minor bugs in commit 30bf4689a96cd283af33edcdd6b7210df3f20cd8 et al. Coverity complained that the "else" added to fillPGconn() was unreachable, which it was. Remove the dead code. In passing, rearrange the tests so as not to bother trying to fetch values for options that can't be assigned. Pre-9.3 did not have that issue, but it did have a "return" that should be "goto oom_error" to ensure that a suitable error message gets filled in.
2014-11-30 18:20:44 +01:00
char **connmember = (char **) ((char *) conn + option->connofs);
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(*connmember);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
*connmember = strdup(tmp);
if (*connmember == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("out of memory\n"));
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
return false;
}
}
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
}
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
}
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
return true;
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
}
/*
* connectOptions1
*
* Internal subroutine to set up connection parameters given an already-
* created PGconn and a conninfo string. Derived settings should be
* processed by calling connectOptions2 next. (We split them because
* PQsetdbLogin overrides defaults in between.)
*
* Returns true if OK, false if trouble (in which case errorMessage is set
* and so is conn->status).
*/
static bool
connectOptions1(PGconn *conn, const char *conninfo)
{
PQconninfoOption *connOptions;
/*
* Parse the conninfo string
*/
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
connOptions = parse_connection_string(conninfo, &conn->errorMessage, true);
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
if (connOptions == NULL)
{
conn->status = CONNECTION_BAD;
/* errorMessage is already set */
return false;
}
/*
* Move option values into conn structure
*/
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!fillPGconn(conn, connOptions))
{
conn->status = CONNECTION_BAD;
PQconninfoFree(connOptions);
return false;
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
/*
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
* Free the option info - all is in conn now
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
*/
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
PQconninfoFree(connOptions);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
return true;
}
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
/*
* Count the number of elements in a simple comma-separated list.
*/
static int
count_comma_separated_elems(const char *input)
{
int n;
n = 1;
for (; *input != '\0'; input++)
{
if (*input == ',')
n++;
}
return n;
}
/*
* Parse a simple comma-separated list.
*
* On each call, returns a malloc'd copy of the next element, and sets *more
* to indicate whether there are any more elements in the list after this,
* and updates *startptr to point to the next element, if any.
*
* On out of memory, returns NULL.
*/
static char *
parse_comma_separated_list(char **startptr, bool *more)
{
char *p;
char *s = *startptr;
char *e;
int len;
/*
* Search for the end of the current element; a comma or end-of-string
* acts as a terminator.
*/
e = s;
while (*e != '\0' && *e != ',')
++e;
*more = (*e == ',');
len = e - s;
p = (char *) malloc(sizeof(char) * (len + 1));
if (p)
{
memcpy(p, s, len);
p[len] = '\0';
}
*startptr = e + 1;
return p;
}
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
/*
* connectOptions2
*
* Compute derived connection options after absorbing all user-supplied info.
*
* Returns true if OK, false if trouble (in which case errorMessage is set
* and so is conn->status).
*/
static bool
connectOptions2(PGconn *conn)
{
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
int i;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
/*
* Allocate memory for details about each host to which we might possibly
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
* try to connect. For that, count the number of elements in the hostaddr
* or host options. If neither is given, assume one host.
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
*/
conn->whichhost = 0;
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
if (conn->pghostaddr && conn->pghostaddr[0] != '\0')
conn->nconnhost = count_comma_separated_elems(conn->pghostaddr);
else if (conn->pghost && conn->pghost[0] != '\0')
conn->nconnhost = count_comma_separated_elems(conn->pghost);
else
conn->nconnhost = 1;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
conn->connhost = (pg_conn_host *)
calloc(conn->nconnhost, sizeof(pg_conn_host));
if (conn->connhost == NULL)
goto oom_error;
/*
* We now have one pg_conn_host structure per possible host. Fill in the
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
* host and hostaddr fields for each, by splitting the parameter strings.
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
*/
if (conn->pghostaddr != NULL && conn->pghostaddr[0] != '\0')
{
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
char *s = conn->pghostaddr;
bool more = true;
for (i = 0; i < conn->nconnhost && more; i++)
{
conn->connhost[i].hostaddr = parse_comma_separated_list(&s, &more);
if (conn->connhost[i].hostaddr == NULL)
goto oom_error;
}
/*
* If hostaddr was given, the array was allocated according to the
* number of elements in the hostaddr list, so it really should be the
* right size.
*/
Assert(!more);
Assert(i == conn->nconnhost);
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
}
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
if (conn->pghost != NULL && conn->pghost[0] != '\0')
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
{
char *s = conn->pghost;
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
bool more = true;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
for (i = 0; i < conn->nconnhost && more; i++)
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
{
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
conn->connhost[i].host = parse_comma_separated_list(&s, &more);
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
if (conn->connhost[i].host == NULL)
goto oom_error;
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
}
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
/* Check for wrong number of host items. */
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
if (more || i != conn->nconnhost)
{
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(&conn->errorMessage,
Fix wording of "hostaddrs" The field is still called "hostaddr", so make sure references use "hostaddr values" instead. Author: Michael Paquier <michael.paquier@gmail.com>
2018-01-21 13:40:55 +01:00
libpq_gettext("could not match %d host names to %d hostaddr values\n"),
Fix check for empty hostname. As reported by Arthur Zakirov, Gcc 7.1 complained about this with -Wpointer-compare. Discussion: https://www.postgresql.org/message-id/CAKNkYnybV_NFVacGbW=VspzAo3TwRJFNi+9iBob66YqQMZopwg@mail.gmail.com
2017-07-10 14:29:36 +02:00
count_comma_separated_elems(conn->pghost), conn->nconnhost);
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
return false;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
}
}
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
/*
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
* Now, for each host slot, identify the type of address spec, and fill in
* the default address if nothing was given.
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
*/
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
for (i = 0; i < conn->nconnhost; i++)
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
{
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
pg_conn_host *ch = &conn->connhost[i];
if (ch->hostaddr != NULL && ch->hostaddr[0] != '\0')
ch->type = CHT_HOST_ADDRESS;
else if (ch->host != NULL && ch->host[0] != '\0')
{
ch->type = CHT_HOST_NAME;
Add support for abstract Unix-domain sockets This is a variant of the normal Unix-domain sockets that don't use the file system but a separate "abstract" namespace. At the user interface, such sockets are represented by names starting with "@". Supported on Linux and Windows right now. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/6dee8574-b0ad-fc49-9c8c-2edc796f0033@2ndquadrant.com
2020-11-25 08:14:23 +01:00
if (is_unixsock_path(ch->host))
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
ch->type = CHT_UNIX_SOCKET;
}
else
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(ch->host);
Fix pg_regress to print the correct postmaster address on Windows. pg_regress reported "Unix socket" as the default location whenever HAVE_UNIX_SOCKETS is defined. However, that's not been accurate on Windows since 8f3ec75de. Update this logic to match what libpq actually does now. This is just cosmetic, but still it's potentially misleading. Back-patch to v13 where 8f3ec75de came in. Discussion: https://postgr.es/m/3894060.1646415641@sss.pgh.pa.us
2022-03-04 19:23:58 +01:00
/*
* This bit selects the default host location. If you change
* this, see also pg_regress.
*/
Allow building without default socket directory We have code paths for Unix socket support and no Unix socket support. Now add a third variant: Unix socket support but do not use a Unix socket by default in the client or the server, only if you explicitly specify one. This will be useful when we enable Unix socket support on Windows. To implement this, tweak things so that setting DEFAULT_PGSOCKET_DIR to "" has the desired effect. This mostly already worked like that; only a few places needed to be adjusted. Notably, the reference to DEFAULT_PGSOCKET_DIR in UNIXSOCK_PATH() could be removed because all callers already resolve an empty socket directory setting with a default if appropriate. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/75f72249-8ae6-322a-63df-4fe03eeccb9f@2ndquadrant.com
2020-01-31 16:26:12 +01:00
if (DEFAULT_PGSOCKET_DIR[0])
{
ch->host = strdup(DEFAULT_PGSOCKET_DIR);
ch->type = CHT_UNIX_SOCKET;
}
else
{
ch->host = strdup(DefaultHost);
ch->type = CHT_HOST_NAME;
}
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
if (ch->host == NULL)
goto oom_error;
}
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
}
/*
* Next, work out the port number corresponding to each host name.
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
*
* Note: unlike the above for host names, this could leave the port fields
* as null or empty strings. We will substitute DEF_PGPORT whenever we
* read such a port field.
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
*/
if (conn->pgport != NULL && conn->pgport[0] != '\0')
{
char *s = conn->pgport;
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
bool more = true;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
for (i = 0; i < conn->nconnhost && more; i++)
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
{
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
conn->connhost[i].port = parse_comma_separated_list(&s, &more);
if (conn->connhost[i].port == NULL)
goto oom_error;
}
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
/*
* If exactly one port was given, use it for every host. Otherwise,
* there must be exactly as many ports as there were hosts.
*/
if (i == 1 && !more)
{
for (i = 1; i < conn->nconnhost; i++)
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
{
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
conn->connhost[i].port = strdup(conn->connhost[0].port);
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
if (conn->connhost[i].port == NULL)
goto oom_error;
}
}
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
else if (more || i != conn->nconnhost)
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
{
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(&conn->errorMessage,
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
libpq_gettext("could not match %d port numbers to %d hosts\n"),
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
count_comma_separated_elems(conn->pgport), conn->nconnhost);
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
return false;
}
}
Fix libpq's behavior when /etc/passwd isn't readable. Some users run their applications in chroot environments that lack an /etc/passwd file. This means that the current UID's user name and home directory are not obtainable. libpq used to be all right with that, so long as the database role name to use was specified explicitly. But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by causing any failure of pg_fe_getauthname() to be treated as a hard error. In any case it did little to advance its nominal goal of causing errors in pg_fe_getauthname() to be reported better. So revert that and instead put some real error-reporting code in place. This requires changes to the APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had departed from the POSIX-specified API of getpwuid_r() in a way that made it impossible to distinguish actual lookup errors from "no such user". To allow such failures to be reported, while not failing if the caller supplies a role name, add a second call of pg_fe_getauthname() in connectOptions2(). This is a tad ugly, and could perhaps be avoided with some refactoring of PQsetdbLogin(), but I'll leave that idea for later. (Note that the complained-of misbehavior only occurs in PQsetdbLogin, not when using the PQconnect functions, because in the latter we will never bother to call pg_fe_getauthname() if the user gives a role name.) In passing also clean up the Windows-side usage of GetUserName(): the recommended buffer size is 257 bytes, the passed buffer length should be the buffer size not buffer size less 1, and any error is reported by GetLastError() not errno. Per report from Christoph Berg. Back-patch to 9.4 where the chroot failure case was introduced. The generally poor reporting of errors here is of very long standing, of course, but given the lack of field complaints about it we won't risk changing these APIs further back (even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
/*
* If user name was not given, fetch it. (Most likely, the fetch will
* fail, since the only way we get here is if pg_fe_getauthname() failed
* during conninfo_add_defaults(). But now we want an error message.)
*/
if (conn->pguser == NULL || conn->pguser[0] == '\0')
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->pguser);
Fix libpq's behavior when /etc/passwd isn't readable. Some users run their applications in chroot environments that lack an /etc/passwd file. This means that the current UID's user name and home directory are not obtainable. libpq used to be all right with that, so long as the database role name to use was specified explicitly. But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by causing any failure of pg_fe_getauthname() to be treated as a hard error. In any case it did little to advance its nominal goal of causing errors in pg_fe_getauthname() to be reported better. So revert that and instead put some real error-reporting code in place. This requires changes to the APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had departed from the POSIX-specified API of getpwuid_r() in a way that made it impossible to distinguish actual lookup errors from "no such user". To allow such failures to be reported, while not failing if the caller supplies a role name, add a second call of pg_fe_getauthname() in connectOptions2(). This is a tad ugly, and could perhaps be avoided with some refactoring of PQsetdbLogin(), but I'll leave that idea for later. (Note that the complained-of misbehavior only occurs in PQsetdbLogin, not when using the PQconnect functions, because in the latter we will never bother to call pg_fe_getauthname() if the user gives a role name.) In passing also clean up the Windows-side usage of GetUserName(): the recommended buffer size is 257 bytes, the passed buffer length should be the buffer size not buffer size less 1, and any error is reported by GetLastError() not errno. Per report from Christoph Berg. Back-patch to 9.4 where the chroot failure case was introduced. The generally poor reporting of errors here is of very long standing, of course, but given the lack of field complaints about it we won't risk changing these APIs further back (even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
conn->pguser = pg_fe_getauthname(&conn->errorMessage);
if (!conn->pguser)
{
conn->status = CONNECTION_BAD;
return false;
}
}
Extended query protocol: parse, bind, execute, describe FE/BE messages. Only lightly tested as yet, since libpq doesn't know anything about 'em.
2003-05-05 02:44:56 +02:00
/*
* If database name was not given, default it to equal user name
*/
Fix libpq's behavior when /etc/passwd isn't readable. Some users run their applications in chroot environments that lack an /etc/passwd file. This means that the current UID's user name and home directory are not obtainable. libpq used to be all right with that, so long as the database role name to use was specified explicitly. But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by causing any failure of pg_fe_getauthname() to be treated as a hard error. In any case it did little to advance its nominal goal of causing errors in pg_fe_getauthname() to be reported better. So revert that and instead put some real error-reporting code in place. This requires changes to the APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had departed from the POSIX-specified API of getpwuid_r() in a way that made it impossible to distinguish actual lookup errors from "no such user". To allow such failures to be reported, while not failing if the caller supplies a role name, add a second call of pg_fe_getauthname() in connectOptions2(). This is a tad ugly, and could perhaps be avoided with some refactoring of PQsetdbLogin(), but I'll leave that idea for later. (Note that the complained-of misbehavior only occurs in PQsetdbLogin, not when using the PQconnect functions, because in the latter we will never bother to call pg_fe_getauthname() if the user gives a role name.) In passing also clean up the Windows-side usage of GetUserName(): the recommended buffer size is 257 bytes, the passed buffer length should be the buffer size not buffer size less 1, and any error is reported by GetLastError() not errno. Per report from Christoph Berg. Back-patch to 9.4 where the chroot failure case was introduced. The generally poor reporting of errors here is of very long standing, of course, but given the lack of field complaints about it we won't risk changing these APIs further back (even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
if (conn->dbName == NULL || conn->dbName[0] == '\0')
Extended query protocol: parse, bind, execute, describe FE/BE messages. Only lightly tested as yet, since libpq doesn't know anything about 'em.
2003-05-05 02:44:56 +02:00
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->dbName);
Extended query protocol: parse, bind, execute, describe FE/BE messages. Only lightly tested as yet, since libpq doesn't know anything about 'em.
2003-05-05 02:44:56 +02:00
conn->dbName = strdup(conn->pguser);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!conn->dbName)
goto oom_error;
Extended query protocol: parse, bind, execute, describe FE/BE messages. Only lightly tested as yet, since libpq doesn't know anything about 'em.
2003-05-05 02:44:56 +02:00
}
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
/*
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
* If password was not given, try to look it up in password file. Note
* that the result might be different for each host/port pair.
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
*/
if (conn->pgpass == NULL || conn->pgpass[0] == '\0')
{
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
/* If password file wasn't specified, use ~/PGPASSFILE */
Allow password file name to be specified as a libpq connection parameter. Formerly an alternate password file could only be selected via the environment variable PGPASSFILE; now it can also be selected via a new connection parameter "passfile", corresponding to the conventions for most other connection parameters. There was some concern about this creating a security weakness, but it was agreed that that argument was pretty thin, and there are clear use-cases for handling password files this way. Julian Markwort, reviewed by Fabien Coelho, some adjustments by me Discussion: https://postgr.es/m/a4b4f4f1-7b58-a0e8-5268-5f7db8e8ccaa@uni-muenster.de
2017-01-24 23:06:21 +01:00
if (conn->pgpassfile == NULL || conn->pgpassfile[0] == '\0')
{
char homedir[MAXPGPATH];
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
if (pqGetHomeDirectory(homedir, sizeof(homedir)))
Allow password file name to be specified as a libpq connection parameter. Formerly an alternate password file could only be selected via the environment variable PGPASSFILE; now it can also be selected via a new connection parameter "passfile", corresponding to the conventions for most other connection parameters. There was some concern about this creating a security weakness, but it was agreed that that argument was pretty thin, and there are clear use-cases for handling password files this way. Julian Markwort, reviewed by Fabien Coelho, some adjustments by me Discussion: https://postgr.es/m/a4b4f4f1-7b58-a0e8-5268-5f7db8e8ccaa@uni-muenster.de
2017-01-24 23:06:21 +01:00
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->pgpassfile);
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
conn->pgpassfile = malloc(MAXPGPATH);
if (!conn->pgpassfile)
goto oom_error;
snprintf(conn->pgpassfile, MAXPGPATH, "%s/%s",
homedir, PGPASSFILE);
Allow password file name to be specified as a libpq connection parameter. Formerly an alternate password file could only be selected via the environment variable PGPASSFILE; now it can also be selected via a new connection parameter "passfile", corresponding to the conventions for most other connection parameters. There was some concern about this creating a security weakness, but it was agreed that that argument was pretty thin, and there are clear use-cases for handling password files this way. Julian Markwort, reviewed by Fabien Coelho, some adjustments by me Discussion: https://postgr.es/m/a4b4f4f1-7b58-a0e8-5268-5f7db8e8ccaa@uni-muenster.de
2017-01-24 23:06:21 +01:00
}
}
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
if (conn->pgpassfile != NULL && conn->pgpassfile[0] != '\0')
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
{
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
for (i = 0; i < conn->nconnhost; i++)
{
/*
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
* Try to get a password for this host from file. We use host
* for the hostname search key if given, else hostaddr (at
* least one of them is guaranteed nonempty by now).
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
*/
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
const char *pwhost = conn->connhost[i].host;
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
if (pwhost == NULL || pwhost[0] == '\0')
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
pwhost = conn->connhost[i].hostaddr;
conn->connhost[i].password =
passwordFromFile(pwhost,
conn->connhost[i].port,
conn->dbName,
conn->pguser,
conn->pgpassfile);
}
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
}
Remove -k unix socketpath option from client side, allow hostname with leading slash to behave as a unix socket path.
2000-11-14 00:37:54 +01:00
}
Add libpq parameter 'channel_binding'. Allow clients to require channel binding to enhance security against untrusted servers. Author: Jeff Davis Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel%40j-davis.com
2019-09-23 22:45:23 +02:00
/*
* validate channel_binding option
*/
if (conn->channel_binding)
{
if (strcmp(conn->channel_binding, "disable") != 0
&& strcmp(conn->channel_binding, "prefer") != 0
&& strcmp(conn->channel_binding, "require") != 0)
{
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(&conn->errorMessage,
Error message refactoring Take some untranslatable things out of the message and replace by format placeholders, to reduce translatable strings and reduce translation mistakes.
2020-06-15 08:22:52 +02:00
libpq_gettext("invalid %s value: \"%s\"\n"),
"channel_binding", conn->channel_binding);
Add libpq parameter 'channel_binding'. Allow clients to require channel binding to enhance security against untrusted servers. Author: Jeff Davis Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel%40j-davis.com
2019-09-23 22:45:23 +02:00
return false;
}
}
else
{
conn->channel_binding = strdup(DefaultChannelBinding);
if (!conn->channel_binding)
goto oom_error;
}
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
/*
* validate sslmode option
*/
if (conn->sslmode)
{
if (strcmp(conn->sslmode, "disable") != 0
&& strcmp(conn->sslmode, "allow") != 0
&& strcmp(conn->sslmode, "prefer") != 0
Remove sslverify parameter again, replacing it with two new sslmode values: "verify-ca" and "verify-full". Since "prefer" remains the default, this will make certificate validation off by default, which should lead to less upgrade issues.
2009-04-24 11:43:10 +02:00
&& strcmp(conn->sslmode, "require") != 0
&& strcmp(conn->sslmode, "verify-ca") != 0
&& strcmp(conn->sslmode, "verify-full") != 0)
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
{
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(&conn->errorMessage,
Error message refactoring Take some untranslatable things out of the message and replace by format placeholders, to reduce translatable strings and reduce translation mistakes.
2020-06-15 08:22:52 +02:00
libpq_gettext("invalid %s value: \"%s\"\n"),
"sslmode", conn->sslmode);
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
return false;
}
#ifndef USE_SSL
switch (conn->sslmode[0])
{
case 'a': /* "allow" */
case 'p': /* "prefer" */
pgindent run.
2003-08-04 02:43:34 +02:00
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
/*
* warn user that an SSL connection will never be negotiated
* since SSL was not compiled in?
*/
break;
case 'r': /* "require" */
Remove sslverify parameter again, replacing it with two new sslmode values: "verify-ca" and "verify-full". Since "prefer" remains the default, this will make certificate validation off by default, which should lead to less upgrade issues.
2009-04-24 11:43:10 +02:00
case 'v': /* "verify-ca" or "verify-full" */
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(&conn->errorMessage,
Message wording improvements
2003-09-22 02:23:35 +02:00
libpq_gettext("sslmode value \"%s\" invalid when SSL support is not compiled in\n"),
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
conn->sslmode);
return false;
}
#endif
}
else
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
{
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
conn->sslmode = strdup(DefaultSSLMode);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!conn->sslmode)
goto oom_error;
}
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
/*
Rename connection parameters to control min/max SSL protocol version in libpq The libpq parameters ssl{max|min}protocolversion are renamed to use underscores, to become ssl_{max|min}_protocol_version. The related environment variables still use the names introduced in commit ff8ca5f that added the feature. Per complaint from Peter Eisentraut (this was also mentioned by me in the original patch review but the issue got discarded). Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com
2020-04-30 06:39:10 +02:00
* Validate TLS protocol versions for ssl_min_protocol_version and
* ssl_max_protocol_version.
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
*/
Rename connection parameters to control min/max SSL protocol version in libpq The libpq parameters ssl{max|min}protocolversion are renamed to use underscores, to become ssl_{max|min}_protocol_version. The related environment variables still use the names introduced in commit ff8ca5f that added the feature. Per complaint from Peter Eisentraut (this was also mentioned by me in the original patch review but the issue got discarded). Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com
2020-04-30 06:39:10 +02:00
if (!sslVerifyProtocolVersion(conn->ssl_min_protocol_version))
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
{
Fix assorted error-cleanup bugs in SSL min/max protocol version code. The error exits added to initialize_SSL() failed to clean up the partially-built SSL_context, and some of them also leaked the result of SSLerrmessage(). Make them match other error-handling cases in that function. The error exits added to connectOptions2() failed to set conn->status like every other error exit in that function. In passing, make the SSL_get_peer_certificate() error exit look more like all the other calls of SSLerrmessage(). Oversights in commit ff8ca5fad. Coverity whined about leakage of the SSLerrmessage() results; I noted the rest in manual code review.
2020-02-02 19:09:33 +01:00
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(&conn->errorMessage,
Error message refactoring Take some untranslatable things out of the message and replace by format placeholders, to reduce translatable strings and reduce translation mistakes.
2020-06-15 08:22:52 +02:00
libpq_gettext("invalid %s value: \"%s\"\n"),
"ssl_min_protocol_version",
Rename connection parameters to control min/max SSL protocol version in libpq The libpq parameters ssl{max|min}protocolversion are renamed to use underscores, to become ssl_{max|min}_protocol_version. The related environment variables still use the names introduced in commit ff8ca5f that added the feature. Per complaint from Peter Eisentraut (this was also mentioned by me in the original patch review but the issue got discarded). Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com
2020-04-30 06:39:10 +02:00
conn->ssl_min_protocol_version);
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
return false;
}
Rename connection parameters to control min/max SSL protocol version in libpq The libpq parameters ssl{max|min}protocolversion are renamed to use underscores, to become ssl_{max|min}_protocol_version. The related environment variables still use the names introduced in commit ff8ca5f that added the feature. Per complaint from Peter Eisentraut (this was also mentioned by me in the original patch review but the issue got discarded). Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com
2020-04-30 06:39:10 +02:00
if (!sslVerifyProtocolVersion(conn->ssl_max_protocol_version))
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
{
Fix assorted error-cleanup bugs in SSL min/max protocol version code. The error exits added to initialize_SSL() failed to clean up the partially-built SSL_context, and some of them also leaked the result of SSLerrmessage(). Make them match other error-handling cases in that function. The error exits added to connectOptions2() failed to set conn->status like every other error exit in that function. In passing, make the SSL_get_peer_certificate() error exit look more like all the other calls of SSLerrmessage(). Oversights in commit ff8ca5fad. Coverity whined about leakage of the SSLerrmessage() results; I noted the rest in manual code review.
2020-02-02 19:09:33 +01:00
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(&conn->errorMessage,
Error message refactoring Take some untranslatable things out of the message and replace by format placeholders, to reduce translatable strings and reduce translation mistakes.
2020-06-15 08:22:52 +02:00
libpq_gettext("invalid %s value: \"%s\"\n"),
"ssl_max_protocol_version",
Rename connection parameters to control min/max SSL protocol version in libpq The libpq parameters ssl{max|min}protocolversion are renamed to use underscores, to become ssl_{max|min}_protocol_version. The related environment variables still use the names introduced in commit ff8ca5f that added the feature. Per complaint from Peter Eisentraut (this was also mentioned by me in the original patch review but the issue got discarded). Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com
2020-04-30 06:39:10 +02:00
conn->ssl_max_protocol_version);
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
return false;
}
/*
* Check if the range of SSL protocols defined is correct. This is done
* at this early step because this is independent of the SSL
* implementation used, and this avoids unnecessary cycles with an
* already-built SSL context when the connection is being established, as
* it would be doomed anyway.
*/
Rename connection parameters to control min/max SSL protocol version in libpq The libpq parameters ssl{max|min}protocolversion are renamed to use underscores, to become ssl_{max|min}_protocol_version. The related environment variables still use the names introduced in commit ff8ca5f that added the feature. Per complaint from Peter Eisentraut (this was also mentioned by me in the original patch review but the issue got discarded). Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com
2020-04-30 06:39:10 +02:00
if (!sslVerifyProtocolRange(conn->ssl_min_protocol_version,
conn->ssl_max_protocol_version))
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
{
Fix assorted error-cleanup bugs in SSL min/max protocol version code. The error exits added to initialize_SSL() failed to clean up the partially-built SSL_context, and some of them also leaked the result of SSLerrmessage(). Make them match other error-handling cases in that function. The error exits added to connectOptions2() failed to set conn->status like every other error exit in that function. In passing, make the SSL_get_peer_certificate() error exit look more like all the other calls of SSLerrmessage(). Oversights in commit ff8ca5fad. Coverity whined about leakage of the SSLerrmessage() results; I noted the rest in manual code review.
2020-02-02 19:09:33 +01:00
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("invalid SSL protocol version range\n"));
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
return false;
}
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
/*
* validate gssencmode option
*/
if (conn->gssencmode)
{
if (strcmp(conn->gssencmode, "disable") != 0 &&
strcmp(conn->gssencmode, "prefer") != 0 &&
strcmp(conn->gssencmode, "require") != 0)
{
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(&conn->errorMessage,
Error message refactoring Take some untranslatable things out of the message and replace by format placeholders, to reduce translatable strings and reduce translation mistakes.
2020-06-15 08:22:52 +02:00
libpq_gettext("invalid %s value: \"%s\"\n"),
"gssencmode",
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
conn->gssencmode);
return false;
}
#ifndef ENABLE_GSS
if (strcmp(conn->gssencmode, "require") == 0)
{
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(&conn->errorMessage,
Message style fixes
2019-09-06 16:12:28 +02:00
libpq_gettext("gssencmode value \"%s\" invalid when GSSAPI support is not compiled in\n"),
conn->gssencmode);
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
return false;
}
#endif
}
else
{
conn->gssencmode = strdup(DefaultGSSMode);
if (!conn->gssencmode)
goto oom_error;
}
Set psql client encoding from locale by default Add a new libpq connection option client_encoding (which includes the existing PGCLIENTENCODING environment variable), which besides an encoding name accepts a special value "auto" that tries to determine the encoding from the locale in the client's environment, using the mechanisms that have been in use in initdb. psql sets this new connection option to "auto" when running from a terminal and not overridden by setting PGCLIENTENCODING. original code by Heikki Linnakangas, with subsequent contributions by Jaime Casanova, Peter Eisentraut, Stephen Frost, Ibrar Ahmed
2011-02-19 07:54:58 +01:00
/*
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
* validate target_session_attrs option, and set target_server_type
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
*/
if (conn->target_session_attrs)
{
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
if (strcmp(conn->target_session_attrs, "any") == 0)
conn->target_server_type = SERVER_TYPE_ANY;
else if (strcmp(conn->target_session_attrs, "read-write") == 0)
conn->target_server_type = SERVER_TYPE_READ_WRITE;
else if (strcmp(conn->target_session_attrs, "read-only") == 0)
conn->target_server_type = SERVER_TYPE_READ_ONLY;
else if (strcmp(conn->target_session_attrs, "primary") == 0)
conn->target_server_type = SERVER_TYPE_PRIMARY;
else if (strcmp(conn->target_session_attrs, "standby") == 0)
conn->target_server_type = SERVER_TYPE_STANDBY;
else if (strcmp(conn->target_session_attrs, "prefer-standby") == 0)
conn->target_server_type = SERVER_TYPE_PREFER_STANDBY;
else
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
{
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(&conn->errorMessage,
Error message refactoring Take some untranslatable things out of the message and replace by format placeholders, to reduce translatable strings and reduce translation mistakes.
2020-06-15 08:22:52 +02:00
libpq_gettext("invalid %s value: \"%s\"\n"),
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
"target_session_attrs",
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
conn->target_session_attrs);
return false;
}
}
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
else
conn->target_server_type = SERVER_TYPE_ANY;
/*
* Resolve special "auto" client_encoding from the locale
*/
if (conn->client_encoding_initial &&
strcmp(conn->client_encoding_initial, "auto") == 0)
{
free(conn->client_encoding_initial);
conn->client_encoding_initial = strdup(pg_encoding_to_char(pg_get_encoding_from_locale(NULL, true)));
if (!conn->client_encoding_initial)
goto oom_error;
}
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
Add positive defense against trying to connect when the connection option state hasn't been fully set up. This is possible via PQreset() and might occur in other code paths too, so a state flag seems the most robust solution. Per report from Arturs Zoldners.
2006-02-13 23:33:57 +01:00
/*
* Only if we get this far is it appropriate to try to connect. (We need a
* state flag, rather than just the boolean result of this function, in
* case someone tries to PQreset() the PGconn.)
*/
conn->options_valid = true;
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
return true;
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
oom_error:
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("out of memory\n"));
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
return false;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
}
Remove some unneeded dashes from libpq comments.
2001-08-17 17:11:15 +02:00
/*
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
* PQconndefaults
*
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
* Construct a default connection options array, which identifies all the
* available options and shows any default values that are available from the
* environment etc. On error (eg out of memory), NULL is returned.
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
*
* Using this function, an application may determine all possible options
* and their current default values.
*
* NOTE: as of PostgreSQL 7.0, the returned array is dynamically allocated
* and should be freed when no longer needed via PQconninfoFree(). (In prior
* versions, the returned array was static, but that's not thread-safe.)
* Pre-7.0 applications that use this function will see a small memory leak
* until they are updated to call PQconninfoFree.
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*/
PQconninfoOption *
All external function definitions now have prototypes that are checked.
1996-11-10 04:06:38 +01:00
PQconndefaults(void)
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
PQExpBufferData errorBuf;
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
PQconninfoOption *connOptions;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
/* We don't actually report any errors here, but callees want a buffer */
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
initPQExpBuffer(&errorBuf);
Suppress remaining -Waddress warnings from recent gcc versions. Still an exercise in satisfying pedants.
2011-10-19 03:44:23 +02:00
if (PQExpBufferDataBroken(errorBuf))
Fix dblink_connect() so that it verifies that a password is supplied in the conninfo string *before* trying to connect to the remote server, not after. As pointed out by Marko Kreen, in certain not-very-plausible situations this could result in sending a password from the postgres user's .pgpass file, or other places that non-superusers shouldn't have access to, to an untrustworthy remote server. The cleanest fix seems to be to expose libpq's conninfo-string-parsing code so that dblink can check for a password option without duplicating the parsing logic. Joe Conway, with a little cleanup by Tom Lane
2008-09-22 15:55:14 +02:00
return NULL; /* out of memory already :-( */
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
connOptions = conninfo_init(&errorBuf);
if (connOptions != NULL)
{
libpq: change PQconndefaults() to ignore invalid service files Previously missing or invalid service files returned NULL. Also fix pg_upgrade to report "out of memory" for a null return from PQconndefaults(). Patch by Steve Singer, rewritten by me
2013-12-03 17:11:56 +01:00
/* pass NULL errorBuf to ignore errors */
if (!conninfo_add_defaults(connOptions, NULL))
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
{
PQconninfoFree(connOptions);
connOptions = NULL;
}
}
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
termPQExpBuffer(&errorBuf);
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
return connOptions;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
}
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/* ----------------
From: todd brandys <brandys@eng3.hep.uiuc.edu> An extension to the code to allow for a pg_password authentication database that is *seperate* from the system password file
1997-12-04 01:28:15 +01:00
* PQsetdbLogin
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*
Add PGUSER environment variable for client to specify Postgres username.
1996-10-10 10:20:11 +02:00
* establishes a connection to a postgres backend through the postmaster
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
* at the specified host and port.
*
* returns a PGconn* which is needed for all subsequent libpq calls
From: Dan McGuirk <mcguirk@indirect.com> Subject: [HACKERS] password authentication This patch adds support for plaintext password authentication. To use it, you add a line like host all 0.0.0.0 0.0.0.0 password pg_pwd.conf to your pg_hba.conf, where 'pg_pwd.conf' is the name of a file containing the usernames and password hashes in the format of the first two fields of a Unix /etc/passwd file. (Of course, you can use a specific database name or IP instead.) Then, to connect with a password through libpq, you use the PQconnectdb() function, specifying the "password=" tag in the connect string and also adding the tag "authtype=password". I also added a command-line switch '-u' to psql that tells it to prompt for a username and password and use password authentication.
1997-03-12 22:23:16 +01:00
*
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
* if the status field of the connection returned is CONNECTION_BAD,
* then only the errorMessage is likely to be useful.
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
* ----------------
*/
PGconn *
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
PQsetdbLogin(const char *pghost, const char *pgport, const char *pgoptions,
const char *pgtty, const char *dbName, const char *login,
const char *pwd)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Reverse out const to libpq interface from D'Arcy.
1999-02-05 05:25:55 +01:00
PGconn *conn;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
/*
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
* Allocate memory for the conn structure. Note that we also expect this
* to initialize conn->errorMessage to empty. All subsequent steps during
* connection initialization will only append to that buffer.
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
*/
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
conn = makeEmptyPGconn();
Fixes: When you connect to a database with PQsetdb, as with psql, depending on how your uninitialized variables are set, you can get a failure with a "There is no connection to the backend" message. The fix is to move a call to PQexec() from inside connectDB() to PQsetdb() after connectDB() returns to PQsetdb(). That way a connection doesn't have to be already established in order to establish it! From: bryanh@giraffe.netgate.net (Bryan Henderson)
1996-08-19 15:25:40 +02:00
if (conn == NULL)
More janitorial work: remove the explicit casting of NULL literals to a pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
2004-01-07 19:56:30 +01:00
return NULL;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Interpret a dbName param to PQsetdbLogin as a conninfo string if it contains an = sign. Tom Lane and Andrew Dunstan.
2006-12-19 02:53:36 +01:00
/*
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
* If the dbName parameter contains what looks like a connection string,
* parse it into conn struct using connectOptions1.
Interpret a dbName param to PQsetdbLogin as a conninfo string if it contains an = sign. Tom Lane and Andrew Dunstan.
2006-12-19 02:53:36 +01:00
*/
Revert "psql: fix \connect with URIs and conninfo strings" This reverts commit fcef1617295c074f2684c887627184d2fc26ac04, about which both the buildfarm and my local machine are very unhappy.
2015-04-02 16:10:22 +02:00
if (dbName && recognized_connection_string(dbName))
Interpret a dbName param to PQsetdbLogin as a conninfo string if it contains an = sign. Tom Lane and Andrew Dunstan.
2006-12-19 02:53:36 +01:00
{
if (!connectOptions1(conn, dbName))
return conn;
}
else
{
/*
* Old-style path: first, parse an empty conninfo string in order to
* set up the same defaults that PQconnectdb() would use.
*/
if (!connectOptions1(conn, ""))
return conn;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Interpret a dbName param to PQsetdbLogin as a conninfo string if it contains an = sign. Tom Lane and Andrew Dunstan.
2006-12-19 02:53:36 +01:00
/* Insert dbName parameter value into struct */
if (dbName && dbName[0] != '\0')
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->dbName);
Interpret a dbName param to PQsetdbLogin as a conninfo string if it contains an = sign. Tom Lane and Andrew Dunstan.
2006-12-19 02:53:36 +01:00
conn->dbName = strdup(dbName);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!conn->dbName)
goto oom_error;
Interpret a dbName param to PQsetdbLogin as a conninfo string if it contains an = sign. Tom Lane and Andrew Dunstan.
2006-12-19 02:53:36 +01:00
}
}
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Interpret a dbName param to PQsetdbLogin as a conninfo string if it contains an = sign. Tom Lane and Andrew Dunstan.
2006-12-19 02:53:36 +01:00
/*
* Insert remaining parameters into struct, overriding defaults (as well
* as any conflicting data from dbName taken as a conninfo).
Remove -k unix socketpath option from client side, allow hostname with leading slash to behave as a unix socket path.
2000-11-14 00:37:54 +01:00
*/
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
if (pghost && pghost[0] != '\0')
Remove -k unix socketpath option from client side, allow hostname with leading slash to behave as a unix socket path.
2000-11-14 00:37:54 +01:00
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->pghost);
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
conn->pghost = strdup(pghost);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!conn->pghost)
goto oom_error;
Remove -k unix socketpath option from client side, allow hostname with leading slash to behave as a unix socket path.
2000-11-14 00:37:54 +01:00
}
UUNET is looking into offering PostgreSQL as a part of a managed web hosting product, on both shared and dedicated machines. We currently offer Oracle and MySQL, and it would be a nice middle-ground. However, as shipped, PostgreSQL lacks the following features we need that MySQL has: 1. The ability to listen only on a particular IP address. Each hosting customer has their own IP address, on which all of their servers (http, ftp, real media, etc.) run. 2. The ability to place the Unix-domain socket in a mode 700 directory. This allows us to automatically create an empty database, with an empty DBA password, for new or upgrading customers without having to interactively set a DBA password and communicate it to (or from) the customer. This in turn cuts down our install and upgrade times. 3. The ability to connect to the Unix-domain socket from within a change-rooted environment. We run CGI programs chrooted to the user's home directory, which is another reason why we need to be able to specify where the Unix-domain socket is, instead of /tmp. 4. The ability to, if run as root, open a pid file in /var/run as root, and then setuid to the desired user. (mysqld -u can almost do this; I had to patch it, too). The patch below fixes problem 1-3. I plan to address #4, also, but haven't done so yet. These diffs are big enough that they should give the PG development team something to think about in the meantime :-) Also, I'm about to leave for 2 weeks' vacation, so I thought I'd get out what I have, which works (for the problems it tackles), now. With these changes, we can set up and run PostgreSQL with scripts the same way we can with apache or proftpd or mysql. In summary, this patch makes the following enhancements: 1. Adds an environment variable PGUNIXSOCKET, analogous to MYSQL_UNIX_PORT, and command line options -k --unix-socket to the relevant programs. 2. Adds a -h option to postmaster to set the hostname or IP address to listen on instead of the default INADDR_ANY. 3. Extends some library interfaces to support the above. 4. Fixes a few memory leaks in PQconnectdb(). The default behavior is unchanged from stock 7.0.2; if you don't use any of these new features, they don't change the operation. David J. MacKenzie
2000-11-13 16:18:15 +01:00
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
if (pgport && pgport[0] != '\0')
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->pgport);
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
conn->pgport = strdup(pgport);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!conn->pgport)
goto oom_error;
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
if (pgoptions && pgoptions[0] != '\0')
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->pgoptions);
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
conn->pgoptions = strdup(pgoptions);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!conn->pgoptions)
goto oom_error;
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
if (login && login[0] != '\0')
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->pguser);
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
conn->pguser = strdup(login);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!conn->pguser)
goto oom_error;
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
if (pwd && pwd[0] != '\0')
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->pgpass);
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
conn->pgpass = strdup(pwd);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!conn->pgpass)
goto oom_error;
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
}
Code review for connection timeout patch. Avoid unportable assumption that tv_sec is signed; return a useful error message on timeout failure; honor PGCONNECT_TIMEOUT environment variable in PQsetdbLogin; make code obey documentation statement that timeout=0 means no timeout.
2002-10-25 01:35:55 +02:00
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
/*
* Compute derived options
*/
if (!connectOptions2(conn))
return conn;
SSL patch from Magnus
2000-08-30 16:54:24 +02:00
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
/*
* Connect to the database
*/
if (connectDBStart(conn))
(void) connectDBComplete(conn);
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Fixes: When you connect to a database with PQsetdb, as with psql, depending on how your uninitialized variables are set, you can get a failure with a "There is no connection to the backend" message. The fix is to move a call to PQexec() from inside connectDB() to PQsetdb() after connectDB() returns to PQsetdb(). That way a connection doesn't have to be already established in order to establish it! From: bryanh@giraffe.netgate.net (Bryan Henderson)
1996-08-19 15:25:40 +02:00
return conn;
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
oom_error:
conn->status = CONNECTION_BAD;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("out of memory\n"));
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
return conn;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/* ----------
* connectNoDelay -
* Sets the TCP_NODELAY socket option.
* Returns 1 if successful, 0 if not.
* ----------
*/
static int
connectNoDelay(PGconn *conn)
{
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
#ifdef TCP_NODELAY
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
int on = 1;
Remove calls to getprotobyname(), which we now know leaks memory on some platforms --- and I also see that it is documented as not thread- safe on HPUX and possibly other platforms. No good reason not to just use IPPROTO_TCP constant from <netinet/in.h> instead.
2000-05-21 23:19:53 +02:00
if (setsockopt(conn->sock, IPPROTO_TCP, TCP_NODELAY,
Big warnings cleanup for Solaris/GCC. Down to about 40 now, but we'll get there one day. Use `cat' to create aclocal.m4, not `aclocal'. Some people don't have automake installed. Only run the autoconf rule in the top-level GNUmakefile if the invoker specified `make configure', don't run it automatically because of CVS timestamp skew.
2000-06-14 20:18:01 +02:00
(char *) &on,
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
sizeof(on)) < 0)
{
Incorporate strerror_r() into src/port/snprintf.c, too. This provides the features that used to exist in useful_strerror() for users of strerror_r(), too. Also, standardize on the GNU convention that strerror_r returns a char pointer that may not be NULL. I notice that libpq's win32.c contains a variant version of strerror_r that probably ought to be folded into strerror.c. But lacking a Windows environment, I should leave that to somebody else. Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
2018-09-26 18:35:57 +02:00
char sebuf[PG_STRERROR_R_BUFLEN];
Make libpq thread-safe with configure --with-threads option. Lee Kindness
2003-06-14 19:49:54 +02:00
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
NLS for libpq. Clean up the message formats and change the documentation accordingly.
2001-07-15 15:45:04 +02:00
libpq_gettext("could not set socket to TCP no delay mode: %s\n"),
Make libpq thread-safe with configure --with-threads option. Lee Kindness
2003-06-14 19:49:54 +02:00
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
return 0;
}
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
#endif
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
return 1;
}
psql: Show IP address in \conninfo When hostaddr is given, the actual IP address that psql is connected to can be totally unexpected for the given host. The more verbose output we now generate makes things clearer. Since the "host" and "hostaddr" parts of the conninfo could come from different sources (say, one of them is in the service specification or a URI-style conninfo and the other is not), this is not as silly as it may first appear. This is also definitely useful if the hostname resolves to multiple addresses. Author: Fabien Coelho Reviewed-by: Pavel Stehule, Arthur Zakirov Discussion: https://postgr.es/m/alpine.DEB.2.21.1810261532380.27686@lancre https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre
2018-11-19 18:34:12 +01:00
/* ----------
* Write currently connected IP address into host_addr (of len host_addr_len).
* If unable to, set it to the empty string.
* ----------
*/
static void
getHostaddr(PGconn *conn, char *host_addr, int host_addr_len)
{
struct sockaddr_storage *addr = &conn->raddr.addr;
Tweak libpq's PQhost, PQhostaddr, and psql's \connect Fixes some problems introduced by 6e5f8d489acc: * When reusing conninfo data from the previous connection in \connect, the host address should only be reused if it was specified as hostaddr; if it wasn't, then 'host' is resolved afresh. We were reusing the same IP address, which ignores a possible DNS change as well as any other addresses that the name resolves to than the one that was used in the original connection. * PQhost, PQhostaddr: Don't present user-specified hostaddr when we have an inet_net_ntop-produced equivalent address. The latter has been put in canonical format, which is cleaner (so it produces "127.0.0.1" when given "host=2130706433", for example). * Document the hostaddr-reusing aspect of \connect. * Fix some code comments Author: Fabien Coelho Reported-by: Noah Misch Discussion: https://postgr.es/m/20190527203713.GA58392@gust.leadboat.com
2019-06-15 00:02:26 +02:00
if (addr->ss_family == AF_INET)
psql: Show IP address in \conninfo When hostaddr is given, the actual IP address that psql is connected to can be totally unexpected for the given host. The more verbose output we now generate makes things clearer. Since the "host" and "hostaddr" parts of the conninfo could come from different sources (say, one of them is in the service specification or a URI-style conninfo and the other is not), this is not as silly as it may first appear. This is also definitely useful if the hostname resolves to multiple addresses. Author: Fabien Coelho Reviewed-by: Pavel Stehule, Arthur Zakirov Discussion: https://postgr.es/m/alpine.DEB.2.21.1810261532380.27686@lancre https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre
2018-11-19 18:34:12 +01:00
{
Avoid conflicts with library versions of inet_net_ntop() and friends. Prefix inet_net_ntop and sibling routines with "pg_" to ensure that they aren't mistaken for C-library functions. This fixes warnings from cpluspluscheck on some platforms, and should help reduce reader confusion everywhere, since our functions aren't exactly interchangeable with the library versions (they may have different ideas about address family codes). This shouldn't be fixing any actual bugs, unless somebody's linker is misbehaving, so no need to back-patch. Discussion: https://postgr.es/m/20518.1559494394@sss.pgh.pa.us
2019-08-19 01:27:23 +02:00
if (pg_inet_net_ntop(AF_INET,
&((struct sockaddr_in *) addr)->sin_addr.s_addr,
32,
host_addr, host_addr_len) == NULL)
psql: Show IP address in \conninfo When hostaddr is given, the actual IP address that psql is connected to can be totally unexpected for the given host. The more verbose output we now generate makes things clearer. Since the "host" and "hostaddr" parts of the conninfo could come from different sources (say, one of them is in the service specification or a URI-style conninfo and the other is not), this is not as silly as it may first appear. This is also definitely useful if the hostname resolves to multiple addresses. Author: Fabien Coelho Reviewed-by: Pavel Stehule, Arthur Zakirov Discussion: https://postgr.es/m/alpine.DEB.2.21.1810261532380.27686@lancre https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre
2018-11-19 18:34:12 +01:00
host_addr[0] = '\0';
}
else if (addr->ss_family == AF_INET6)
{
Avoid conflicts with library versions of inet_net_ntop() and friends. Prefix inet_net_ntop and sibling routines with "pg_" to ensure that they aren't mistaken for C-library functions. This fixes warnings from cpluspluscheck on some platforms, and should help reduce reader confusion everywhere, since our functions aren't exactly interchangeable with the library versions (they may have different ideas about address family codes). This shouldn't be fixing any actual bugs, unless somebody's linker is misbehaving, so no need to back-patch. Discussion: https://postgr.es/m/20518.1559494394@sss.pgh.pa.us
2019-08-19 01:27:23 +02:00
if (pg_inet_net_ntop(AF_INET6,
&((struct sockaddr_in6 *) addr)->sin6_addr.s6_addr,
128,
host_addr, host_addr_len) == NULL)
psql: Show IP address in \conninfo When hostaddr is given, the actual IP address that psql is connected to can be totally unexpected for the given host. The more verbose output we now generate makes things clearer. Since the "host" and "hostaddr" parts of the conninfo could come from different sources (say, one of them is in the service specification or a URI-style conninfo and the other is not), this is not as silly as it may first appear. This is also definitely useful if the hostname resolves to multiple addresses. Author: Fabien Coelho Reviewed-by: Pavel Stehule, Arthur Zakirov Discussion: https://postgr.es/m/alpine.DEB.2.21.1810261532380.27686@lancre https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre
2018-11-19 18:34:12 +01:00
host_addr[0] = '\0';
}
else
host_addr[0] = '\0';
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
Improve new wording of libpq's connection failure messages. "connection to server so-and-so failed:" seems clearer than the previous wording "could not connect to so-and-so:" (introduced by 52a10224e), because the latter suggests a network-level connection failure. We're now prefixing this string to all types of connection failures, for instance authentication failures; so we need wording that doesn't imply a low-level error. Per discussion with Robert Haas. Discussion: https://postgr.es/m/CA+TgmobssJ6rS22dspWnu-oDxXevGmhMD8VcRBjmj-b9UDqRjw@mail.gmail.com
2021-01-21 22:10:18 +01:00
/*
* emitHostIdentityInfo -
* Speculatively append "connection to server so-and-so failed: " to
* conn->errorMessage once we've identified the current connection target
* address. This ensures that any subsequent error message will be properly
* attributed to the server we couldn't connect to. conn->raddr must be
* valid, and the result of getHostaddr() must be supplied.
Repair residual sillinesses from UUNET virtual host/socket path patch. I hope all the dust has settled out now ...
2000-12-01 00:20:51 +01:00
*/
static void
Improve new wording of libpq's connection failure messages. "connection to server so-and-so failed:" seems clearer than the previous wording "could not connect to so-and-so:" (introduced by 52a10224e), because the latter suggests a network-level connection failure. We're now prefixing this string to all types of connection failures, for instance authentication failures; so we need wording that doesn't imply a low-level error. Per discussion with Robert Haas. Discussion: https://postgr.es/m/CA+TgmobssJ6rS22dspWnu-oDxXevGmhMD8VcRBjmj-b9UDqRjw@mail.gmail.com
2021-01-21 22:10:18 +01:00
emitHostIdentityInfo(PGconn *conn, const char *host_addr)
Repair residual sillinesses from UUNET virtual host/socket path patch. I hope all the dust has settled out now ...
2000-12-01 00:20:51 +01:00
{
Remove IS_AF_UNIX macro The AF_UNIX macro was being used unprotected by HAVE_UNIX_SOCKETS, apparently since 2008. So the redirection through IS_AF_UNIX() is apparently no longer necessary. (More generally, all supported platforms are now HAVE_UNIX_SOCKETS, but even if there were a new platform in the future, it seems plausible that it would define the AF_UNIX symbol even without kernel support.) So remove the IS_AF_UNIX() macro and make the code a bit more consistent. Discussion: https://www.postgresql.org/message-id/flat/f2d26815-9832-e333-d52d-72fbc0ade896%40enterprisedb.com
2022-02-15 10:03:52 +01:00
if (conn->raddr.addr.ss_family == AF_UNIX)
Have a go at fixing various outstanding portability issues in code that was modified for IPv6. Use a robust definition of struct sockaddr_storage, do a proper configure test to see if ss_len exists, don't assume that getnameinfo() will handle AF_UNIX sockets, don't trust getaddrinfo to return the protocol we ask for, etc. This incorporates several outstanding patches from Kurt Roeckx, but I'm to blame for anything that doesn't work ...
2003-07-24 01:30:41 +02:00
{
char service[NI_MAXHOST];
Clean up libpq's pollution of application namespace by renaming the exported routines of ip.c, md5.c, and fe-auth.c to begin with 'pg_'. Also get rid of the vestigial fe_setauthsvc/fe_getauthsvc routines altogether.
2005-10-17 18:24:20 +02:00
pg_getnameinfo_all(&conn->raddr.addr, conn->raddr.salen,
NULL, 0,
service, sizeof(service),
NI_NUMERICSERV);
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
Improve new wording of libpq's connection failure messages. "connection to server so-and-so failed:" seems clearer than the previous wording "could not connect to so-and-so:" (introduced by 52a10224e), because the latter suggests a network-level connection failure. We're now prefixing this string to all types of connection failures, for instance authentication failures; so we need wording that doesn't imply a low-level error. Per discussion with Robert Haas. Discussion: https://postgr.es/m/CA+TgmobssJ6rS22dspWnu-oDxXevGmhMD8VcRBjmj-b9UDqRjw@mail.gmail.com
2021-01-21 22:10:18 +01:00
libpq_gettext("connection to server on socket \"%s\" failed: "),
Have a go at fixing various outstanding portability issues in code that was modified for IPv6. Use a robust definition of struct sockaddr_storage, do a proper configure test to see if ss_len exists, don't assume that getnameinfo() will handle AF_UNIX sockets, don't trust getaddrinfo to return the protocol we ask for, etc. This incorporates several outstanding patches from Kurt Roeckx, but I'm to blame for anything that doesn't work ...
2003-07-24 01:30:41 +02:00
service);
}
Repair residual sillinesses from UUNET virtual host/socket path patch. I hope all the dust has settled out now ...
2000-12-01 00:20:51 +01:00
else
Have a go at fixing various outstanding portability issues in code that was modified for IPv6. Use a robust definition of struct sockaddr_storage, do a proper configure test to see if ss_len exists, don't assume that getnameinfo() will handle AF_UNIX sockets, don't trust getaddrinfo to return the protocol we ask for, etc. This incorporates several outstanding patches from Kurt Roeckx, but I'm to blame for anything that doesn't work ...
2003-07-24 01:30:41 +02:00
{
Fix untranslatable assembly of libpq connection failure message Even though this only affects the insertion of a parenthesized word, it's unwise to assume that parentheses can pass through untranslated. And in any case, the new version is clearer in the code and for translators.
2011-05-19 21:56:53 +02:00
const char *displayed_host;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
const char *displayed_port;
When reporting the server as not responding, if the hostname was supplied, also print the IP address. This allows IPv4 and IPv6 failures to be distinguished. Also useful when a hostname resolves to multiple IP addresses. Also, remove use of inet_ntoa() and use our own inet_net_ntop() in all places, including in libpq, because it is thread-safe.
2010-11-24 23:04:19 +01:00
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
/* To which host and port were we actually connecting? */
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
if (conn->connhost[conn->whichhost].type == CHT_HOST_ADDRESS)
displayed_host = conn->connhost[conn->whichhost].hostaddr;
else
displayed_host = conn->connhost[conn->whichhost].host;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
displayed_port = conn->connhost[conn->whichhost].port;
if (displayed_port == NULL || displayed_port[0] == '\0')
displayed_port = DEF_PGPORT_STR;
Fix untranslatable assembly of libpq connection failure message Even though this only affects the insertion of a parenthesized word, it's unwise to assume that parentheses can pass through untranslated. And in any case, the new version is clearer in the code and for translators.
2011-05-19 21:56:53 +02:00
Properly print the IP number and "localhost" for failed localhost connections when the server is down, on Win32.
2010-12-18 17:25:41 +01:00
/*
* If the user did not supply an IP address using 'hostaddr', and
* 'host' was missing or does not match our lookup, display the
* looked-up IP address.
*/
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
if (conn->connhost[conn->whichhost].type != CHT_HOST_ADDRESS &&
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
host_addr[0] &&
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
strcmp(displayed_host, host_addr) != 0)
Fix untranslatable assembly of libpq connection failure message Even though this only affects the insertion of a parenthesized word, it's unwise to assume that parentheses can pass through untranslated. And in any case, the new version is clearer in the code and for translators.
2011-05-19 21:56:53 +02:00
appendPQExpBuffer(&conn->errorMessage,
Improve new wording of libpq's connection failure messages. "connection to server so-and-so failed:" seems clearer than the previous wording "could not connect to so-and-so:" (introduced by 52a10224e), because the latter suggests a network-level connection failure. We're now prefixing this string to all types of connection failures, for instance authentication failures; so we need wording that doesn't imply a low-level error. Per discussion with Robert Haas. Discussion: https://postgr.es/m/CA+TgmobssJ6rS22dspWnu-oDxXevGmhMD8VcRBjmj-b9UDqRjw@mail.gmail.com
2021-01-21 22:10:18 +01:00
libpq_gettext("connection to server at \"%s\" (%s), port %s failed: "),
psql: Show IP address in \conninfo When hostaddr is given, the actual IP address that psql is connected to can be totally unexpected for the given host. The more verbose output we now generate makes things clearer. Since the "host" and "hostaddr" parts of the conninfo could come from different sources (say, one of them is in the service specification or a URI-style conninfo and the other is not), this is not as silly as it may first appear. This is also definitely useful if the hostname resolves to multiple addresses. Author: Fabien Coelho Reviewed-by: Pavel Stehule, Arthur Zakirov Discussion: https://postgr.es/m/alpine.DEB.2.21.1810261532380.27686@lancre https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre
2018-11-19 18:34:12 +01:00
displayed_host, host_addr,
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
displayed_port);
Fix untranslatable assembly of libpq connection failure message Even though this only affects the insertion of a parenthesized word, it's unwise to assume that parentheses can pass through untranslated. And in any case, the new version is clearer in the code and for translators.
2011-05-19 21:56:53 +02:00
else
appendPQExpBuffer(&conn->errorMessage,
Improve new wording of libpq's connection failure messages. "connection to server so-and-so failed:" seems clearer than the previous wording "could not connect to so-and-so:" (introduced by 52a10224e), because the latter suggests a network-level connection failure. We're now prefixing this string to all types of connection failures, for instance authentication failures; so we need wording that doesn't imply a low-level error. Per discussion with Robert Haas. Discussion: https://postgr.es/m/CA+TgmobssJ6rS22dspWnu-oDxXevGmhMD8VcRBjmj-b9UDqRjw@mail.gmail.com
2021-01-21 22:10:18 +01:00
libpq_gettext("connection to server at \"%s\", port %s failed: "),
Fix untranslatable assembly of libpq connection failure message Even though this only affects the insertion of a parenthesized word, it's unwise to assume that parentheses can pass through untranslated. And in any case, the new version is clearer in the code and for translators.
2011-05-19 21:56:53 +02:00
displayed_host,
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
displayed_port);
Have a go at fixing various outstanding portability issues in code that was modified for IPv6. Use a robust definition of struct sockaddr_storage, do a proper configure test to see if ss_len exists, don't assume that getnameinfo() will handle AF_UNIX sockets, don't trust getaddrinfo to return the protocol we ask for, etc. This incorporates several outstanding patches from Kurt Roeckx, but I'm to blame for anything that doesn't work ...
2003-07-24 01:30:41 +02:00
}
Repair residual sillinesses from UUNET virtual host/socket path patch. I hope all the dust has settled out now ...
2000-12-01 00:20:51 +01:00
}
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
/* ----------
* connectFailureMessage -
* create a friendly error message on connection failure,
* using the given errno value. Use this for error cases that
* imply that there's no server there.
* ----------
*/
static void
connectFailureMessage(PGconn *conn, int errorno)
{
char sebuf[PG_STRERROR_R_BUFLEN];
appendPQExpBuffer(&conn->errorMessage,
"%s\n",
SOCK_STRERROR(errorno, sebuf, sizeof(sebuf)));
Remove IS_AF_UNIX macro The AF_UNIX macro was being used unprotected by HAVE_UNIX_SOCKETS, apparently since 2008. So the redirection through IS_AF_UNIX() is apparently no longer necessary. (More generally, all supported platforms are now HAVE_UNIX_SOCKETS, but even if there were a new platform in the future, it seems plausible that it would define the AF_UNIX symbol even without kernel support.) So remove the IS_AF_UNIX() macro and make the code a bit more consistent. Discussion: https://www.postgresql.org/message-id/flat/f2d26815-9832-e333-d52d-72fbc0ade896%40enterprisedb.com
2022-02-15 10:03:52 +01:00
if (conn->raddr.addr.ss_family == AF_UNIX)
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("\tIs the server running locally and accepting connections on that socket?\n"));
else
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("\tIs the server running on that host and accepting TCP/IP connections?\n"));
}
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
/*
* Should we use keepalives? Returns 1 if yes, 0 if no, and -1 if
* conn->keepalives is set to a value which is not parseable as an
* integer.
*/
static int
useKeepalives(PGconn *conn)
{
char *ep;
int val;
if (conn->keepalives == NULL)
return 1;
val = strtol(conn->keepalives, &ep, 10);
if (*ep)
return -1;
return val != 0 ? 1 : 0;
}
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
/*
* Parse and try to interpret "value" as an integer value, and if successful,
* store it in *result, complaining if there is any trailing garbage or an
Fix parsing of integer values for connection parameters in libpq Commit e7a2217 has introduced stricter checks for integer values in connection parameters for libpq. However this failed to correctly check after trailing whitespaces, while leading whitespaces were discarded per the use of strtol(3). This fixes and refactors the parsing logic to handle both cases consistently. Note that trying to restrict the use of trailing whitespaces can easily break connection strings like in ECPG regression tests (these have allowed me to catch the parsing bug with connect_timeout). Author: Michael Paquier Reviewed-by: Lars Kanis Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de Backpatch-through: 12
2019-10-21 04:17:13 +02:00
* overflow. This allows any number of leading and trailing whitespaces.
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
*/
static bool
parse_int_param(const char *value, int *result, PGconn *conn,
const char *context)
{
char *end;
long numval;
Fix thinkos from 4f4061b for libpq integer parsing A check was redundant. While on it, add an assertion to make sure that the parsing routine is never called with a NULL input. All the code paths currently calling the parsing routine are careful with NULL inputs already, but future callers may forget that. Reported-by: Peter Eisentraut, Lars Kanis Discussion: https://postgr.es/m/ec64956b-4597-56b6-c3db-457d15250fe4@2ndquadrant.com Backpatch-through: 12
2019-10-23 04:34:18 +02:00
Assert(value != NULL);
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
*result = 0;
Fix parsing of integer values for connection parameters in libpq Commit e7a2217 has introduced stricter checks for integer values in connection parameters for libpq. However this failed to correctly check after trailing whitespaces, while leading whitespaces were discarded per the use of strtol(3). This fixes and refactors the parsing logic to handle both cases consistently. Note that trying to restrict the use of trailing whitespaces can easily break connection strings like in ECPG regression tests (these have allowed me to catch the parsing bug with connect_timeout). Author: Michael Paquier Reviewed-by: Lars Kanis Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de Backpatch-through: 12
2019-10-21 04:17:13 +02:00
/* strtol(3) skips leading whitespaces */
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
errno = 0;
numval = strtol(value, &end, 10);
Fix parsing of integer values for connection parameters in libpq Commit e7a2217 has introduced stricter checks for integer values in connection parameters for libpq. However this failed to correctly check after trailing whitespaces, while leading whitespaces were discarded per the use of strtol(3). This fixes and refactors the parsing logic to handle both cases consistently. Note that trying to restrict the use of trailing whitespaces can easily break connection strings like in ECPG regression tests (these have allowed me to catch the parsing bug with connect_timeout). Author: Michael Paquier Reviewed-by: Lars Kanis Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de Backpatch-through: 12
2019-10-21 04:17:13 +02:00
/*
* If no progress was done during the parsing or an error happened, fail.
* This tests properly for overflows of the result.
*/
if (value == end || errno != 0 || numval != (int) numval)
goto error;
/*
* Skip any trailing whitespace; if anything but whitespace remains before
* the terminating character, fail
*/
Fix thinkos from 4f4061b for libpq integer parsing A check was redundant. While on it, add an assertion to make sure that the parsing routine is never called with a NULL input. All the code paths currently calling the parsing routine are careful with NULL inputs already, but future callers may forget that. Reported-by: Peter Eisentraut, Lars Kanis Discussion: https://postgr.es/m/ec64956b-4597-56b6-c3db-457d15250fe4@2ndquadrant.com Backpatch-through: 12
2019-10-23 04:34:18 +02:00
while (*end != '\0' && isspace((unsigned char) *end))
Fix parsing of integer values for connection parameters in libpq Commit e7a2217 has introduced stricter checks for integer values in connection parameters for libpq. However this failed to correctly check after trailing whitespaces, while leading whitespaces were discarded per the use of strtol(3). This fixes and refactors the parsing logic to handle both cases consistently. Note that trying to restrict the use of trailing whitespaces can easily break connection strings like in ECPG regression tests (these have allowed me to catch the parsing bug with connect_timeout). Author: Michael Paquier Reviewed-by: Lars Kanis Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de Backpatch-through: 12
2019-10-21 04:17:13 +02:00
end++;
Fix thinkos from 4f4061b for libpq integer parsing A check was redundant. While on it, add an assertion to make sure that the parsing routine is never called with a NULL input. All the code paths currently calling the parsing routine are careful with NULL inputs already, but future callers may forget that. Reported-by: Peter Eisentraut, Lars Kanis Discussion: https://postgr.es/m/ec64956b-4597-56b6-c3db-457d15250fe4@2ndquadrant.com Backpatch-through: 12
2019-10-23 04:34:18 +02:00
if (*end != '\0')
Fix parsing of integer values for connection parameters in libpq Commit e7a2217 has introduced stricter checks for integer values in connection parameters for libpq. However this failed to correctly check after trailing whitespaces, while leading whitespaces were discarded per the use of strtol(3). This fixes and refactors the parsing logic to handle both cases consistently. Note that trying to restrict the use of trailing whitespaces can easily break connection strings like in ECPG regression tests (these have allowed me to catch the parsing bug with connect_timeout). Author: Michael Paquier Reviewed-by: Lars Kanis Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de Backpatch-through: 12
2019-10-21 04:17:13 +02:00
goto error;
*result = numval;
return true;
error:
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
appendPQExpBuffer(&conn->errorMessage,
Message style fixes
2019-09-06 16:12:28 +02:00
libpq_gettext("invalid integer value \"%s\" for connection option \"%s\"\n"),
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
value, context);
return false;
}
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
#ifndef WIN32
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
/*
* Set the keepalive idle timer.
*/
static int
setKeepalivesIdle(PGconn *conn)
{
int idle;
if (conn->keepalives_idle == NULL)
return 1;
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
if (!parse_int_param(conn->keepalives_idle, &idle, conn,
"keepalives_idle"))
return 0;
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
if (idle < 0)
idle = 0;
Second try at fixing tcp_keepalives_idle option on Solaris. Buildfarm evidence shows that TCP_KEEPALIVE_THRESHOLD doesn't exist after all on Solaris < 11. This means we need to take positive action to prevent the TCP_KEEPALIVE code path from being taken on that platform. I've chosen to limit it with "&& defined(__darwin__)", since it's unclear that anyone else would follow Apple's precedent of spelling the symbol that way. Also, follow a suggestion from Michael Paquier of eliminating code duplication by defining a couple of intermediate symbols for the socket option. In passing, make some effort to reduce the number of translatable messages by replacing "setsockopt(foo) failed" with "setsockopt(%s) failed", etc, throughout the affected files. And update relevant documentation so that it doesn't claim to provide an exhaustive list of the possible socket option names. Like the previous commit (f0256c774), back-patch to all supported branches. Discussion: https://postgr.es/m/20170627163757.25161.528@wrigleys.postgresql.org
2017-06-28 18:30:16 +02:00
#ifdef PG_TCP_KEEPALIVE_IDLE
if (setsockopt(conn->sock, IPPROTO_TCP, PG_TCP_KEEPALIVE_IDLE,
Support setting the keepalive idle time on MacOS X. MacOS X uses TCP_KEEPALIVE rather than TCP_KEEPIDLE for this purpose. Thanks to Fujii Masao for the review.
2010-07-06 23:14:25 +02:00
(char *) &idle, sizeof(idle)) < 0)
{
Incorporate strerror_r() into src/port/snprintf.c, too. This provides the features that used to exist in useful_strerror() for users of strerror_r(), too. Also, standardize on the GNU convention that strerror_r returns a char pointer that may not be NULL. I notice that libpq's win32.c contains a variant version of strerror_r that probably ought to be folded into strerror.c. But lacking a Windows environment, I should leave that to somebody else. Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
2018-09-26 18:35:57 +02:00
char sebuf[PG_STRERROR_R_BUFLEN];
Support setting the keepalive idle time on MacOS X. MacOS X uses TCP_KEEPALIVE rather than TCP_KEEPIDLE for this purpose. Thanks to Fujii Masao for the review.
2010-07-06 23:14:25 +02:00
appendPQExpBuffer(&conn->errorMessage,
Factor out system call names from error messages Instead, put them in via a format placeholder. This reduces the number of distinct translatable messages and also reduces the chances of typos during translation. We already did this for the system call arguments in a number of cases, so this is just the same thing taken a bit further. Discussion: https://www.postgresql.org/message-id/flat/92d6f545-5102-65d8-3c87-489f71ea0a37%40enterprisedb.com
2021-04-23 14:18:11 +02:00
libpq_gettext("%s(%s) failed: %s\n"),
"setsockopt",
Second try at fixing tcp_keepalives_idle option on Solaris. Buildfarm evidence shows that TCP_KEEPALIVE_THRESHOLD doesn't exist after all on Solaris < 11. This means we need to take positive action to prevent the TCP_KEEPALIVE code path from being taken on that platform. I've chosen to limit it with "&& defined(__darwin__)", since it's unclear that anyone else would follow Apple's precedent of spelling the symbol that way. Also, follow a suggestion from Michael Paquier of eliminating code duplication by defining a couple of intermediate symbols for the socket option. In passing, make some effort to reduce the number of translatable messages by replacing "setsockopt(foo) failed" with "setsockopt(%s) failed", etc, throughout the affected files. And update relevant documentation so that it doesn't claim to provide an exhaustive list of the possible socket option names. Like the previous commit (f0256c774), back-patch to all supported branches. Discussion: https://postgr.es/m/20170627163757.25161.528@wrigleys.postgresql.org
2017-06-28 18:30:16 +02:00
PG_TCP_KEEPALIVE_IDLE_STR,
Support setting the keepalive idle time on MacOS X. MacOS X uses TCP_KEEPALIVE rather than TCP_KEEPIDLE for this purpose. Thanks to Fujii Masao for the review.
2010-07-06 23:14:25 +02:00
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
return 0;
}
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
#endif
return 1;
}
/*
* Set the keepalive interval.
*/
static int
setKeepalivesInterval(PGconn *conn)
{
int interval;
if (conn->keepalives_interval == NULL)
return 1;
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
if (!parse_int_param(conn->keepalives_interval, &interval, conn,
"keepalives_interval"))
return 0;
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
if (interval < 0)
interval = 0;
#ifdef TCP_KEEPINTVL
if (setsockopt(conn->sock, IPPROTO_TCP, TCP_KEEPINTVL,
(char *) &interval, sizeof(interval)) < 0)
{
Incorporate strerror_r() into src/port/snprintf.c, too. This provides the features that used to exist in useful_strerror() for users of strerror_r(), too. Also, standardize on the GNU convention that strerror_r returns a char pointer that may not be NULL. I notice that libpq's win32.c contains a variant version of strerror_r that probably ought to be folded into strerror.c. But lacking a Windows environment, I should leave that to somebody else. Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
2018-09-26 18:35:57 +02:00
char sebuf[PG_STRERROR_R_BUFLEN];
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
appendPQExpBuffer(&conn->errorMessage,
Factor out system call names from error messages Instead, put them in via a format placeholder. This reduces the number of distinct translatable messages and also reduces the chances of typos during translation. We already did this for the system call arguments in a number of cases, so this is just the same thing taken a bit further. Discussion: https://www.postgresql.org/message-id/flat/92d6f545-5102-65d8-3c87-489f71ea0a37%40enterprisedb.com
2021-04-23 14:18:11 +02:00
libpq_gettext("%s(%s) failed: %s\n"),
"setsockopt",
Second try at fixing tcp_keepalives_idle option on Solaris. Buildfarm evidence shows that TCP_KEEPALIVE_THRESHOLD doesn't exist after all on Solaris < 11. This means we need to take positive action to prevent the TCP_KEEPALIVE code path from being taken on that platform. I've chosen to limit it with "&& defined(__darwin__)", since it's unclear that anyone else would follow Apple's precedent of spelling the symbol that way. Also, follow a suggestion from Michael Paquier of eliminating code duplication by defining a couple of intermediate symbols for the socket option. In passing, make some effort to reduce the number of translatable messages by replacing "setsockopt(foo) failed" with "setsockopt(%s) failed", etc, throughout the affected files. And update relevant documentation so that it doesn't claim to provide an exhaustive list of the possible socket option names. Like the previous commit (f0256c774), back-patch to all supported branches. Discussion: https://postgr.es/m/20170627163757.25161.528@wrigleys.postgresql.org
2017-06-28 18:30:16 +02:00
"TCP_KEEPINTVL",
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
return 0;
}
#endif
return 1;
}
/*
* Set the count of lost keepalive packets that will trigger a connection
* break.
*/
static int
setKeepalivesCount(PGconn *conn)
{
int count;
if (conn->keepalives_count == NULL)
return 1;
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
if (!parse_int_param(conn->keepalives_count, &count, conn,
"keepalives_count"))
return 0;
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
if (count < 0)
count = 0;
#ifdef TCP_KEEPCNT
if (setsockopt(conn->sock, IPPROTO_TCP, TCP_KEEPCNT,
(char *) &count, sizeof(count)) < 0)
{
Incorporate strerror_r() into src/port/snprintf.c, too. This provides the features that used to exist in useful_strerror() for users of strerror_r(), too. Also, standardize on the GNU convention that strerror_r returns a char pointer that may not be NULL. I notice that libpq's win32.c contains a variant version of strerror_r that probably ought to be folded into strerror.c. But lacking a Windows environment, I should leave that to somebody else. Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
2018-09-26 18:35:57 +02:00
char sebuf[PG_STRERROR_R_BUFLEN];
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
appendPQExpBuffer(&conn->errorMessage,
Factor out system call names from error messages Instead, put them in via a format placeholder. This reduces the number of distinct translatable messages and also reduces the chances of typos during translation. We already did this for the system call arguments in a number of cases, so this is just the same thing taken a bit further. Discussion: https://www.postgresql.org/message-id/flat/92d6f545-5102-65d8-3c87-489f71ea0a37%40enterprisedb.com
2021-04-23 14:18:11 +02:00
libpq_gettext("%s(%s) failed: %s\n"),
"setsockopt",
Second try at fixing tcp_keepalives_idle option on Solaris. Buildfarm evidence shows that TCP_KEEPALIVE_THRESHOLD doesn't exist after all on Solaris < 11. This means we need to take positive action to prevent the TCP_KEEPALIVE code path from being taken on that platform. I've chosen to limit it with "&& defined(__darwin__)", since it's unclear that anyone else would follow Apple's precedent of spelling the symbol that way. Also, follow a suggestion from Michael Paquier of eliminating code duplication by defining a couple of intermediate symbols for the socket option. In passing, make some effort to reduce the number of translatable messages by replacing "setsockopt(foo) failed" with "setsockopt(%s) failed", etc, throughout the affected files. And update relevant documentation so that it doesn't claim to provide an exhaustive list of the possible socket option names. Like the previous commit (f0256c774), back-patch to all supported branches. Discussion: https://postgr.es/m/20170627163757.25161.528@wrigleys.postgresql.org
2017-06-28 18:30:16 +02:00
"TCP_KEEPCNT",
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
return 0;
}
#endif
return 1;
}
Support tcp_keepalives_idle option on Solaris. Turns out that the socket option for this is named TCP_KEEPALIVE_THRESHOLD, at least according to the tcp(7P) man page for Solaris 11. (But since that text refers to "SunOS", it's likely pretty ancient.) It appears that the symbol TCP_KEEPALIVE does get defined on that platform, but it doesn't seem to represent a valid protocol-level socket option. This leads to bleats in the postmaster log, and no tcp_keepalives_idle functionality. Per bug #14720 from Andrey Lizenko, as well as an earlier report from Dhiraj Chawla that nobody had followed up on. The issue's been there since we added the TCP_KEEPALIVE code path in commit 5acd417c8, so back-patch to all supported branches. Discussion: https://postgr.es/m/20170627163757.25161.528@wrigleys.postgresql.org
2017-06-28 00:47:57 +02:00
#else /* WIN32 */
Make the Windows tcp keepalive support depend on the existance of the SIO_KEEPALIVE_VALS define instead of just WIN32, since MingW doesn't support this API (yet?).
2010-07-08 18:19:50 +02:00
#ifdef SIO_KEEPALIVE_VALS
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
/*
* Enable keepalives and set the keepalive values on Win32,
* where they are always set in one batch.
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
*
* CAUTION: This needs to be signal safe, since it's used by PQcancel.
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
*/
static int
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
setKeepalivesWin32(pgsocket sock, int idle, int interval)
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
{
struct tcp_keepalive ka;
DWORD retsize;
if (idle <= 0)
idle = 2 * 60 * 60; /* 2 hours = default */
if (interval <= 0)
interval = 1; /* 1 second = default */
ka.onoff = 1;
ka.keepalivetime = idle * 1000;
ka.keepaliveinterval = interval * 1000;
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
if (WSAIoctl(sock,
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
SIO_KEEPALIVE_VALS,
(LPVOID) &ka,
sizeof(ka),
NULL,
0,
&retsize,
NULL,
NULL)
!= 0)
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
return 0;
return 1;
}
static int
prepKeepalivesWin32(PGconn *conn)
{
int idle = -1;
int interval = -1;
if (conn->keepalives_idle &&
!parse_int_param(conn->keepalives_idle, &idle, conn,
"keepalives_idle"))
return 0;
if (conn->keepalives_interval &&
!parse_int_param(conn->keepalives_interval, &interval, conn,
"keepalives_interval"))
return 0;
if (!setKeepalivesWin32(conn->sock, idle, interval))
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
{
appendPQExpBuffer(&conn->errorMessage,
Factor out system call names from error messages One more that ought to have been part of 82c3cd974131d7fa1cfcd07cebfb04fffe26ee35.
2021-05-03 07:27:31 +02:00
libpq_gettext("%s(%s) failed: error code %d\n"),
"WSAIoctl", "SIO_KEEPALIVE_VALS",
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
WSAGetLastError());
return 0;
}
return 1;
}
Make the Windows tcp keepalive support depend on the existance of the SIO_KEEPALIVE_VALS define instead of just WIN32, since MingW doesn't support this API (yet?).
2010-07-08 18:19:50 +02:00
#endif /* SIO_KEEPALIVE_VALS */
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
#endif /* WIN32 */
Repair residual sillinesses from UUNET virtual host/socket path patch. I hope all the dust has settled out now ...
2000-12-01 00:20:51 +01:00
Add support TCP user timeout in libpq and the backend server Similarly to the set of parameters for keepalive, a connection parameter for libpq is added as well as a backend GUC, called tcp_user_timeout. Increasing the TCP user timeout is useful to allow a connection to survive extended periods without end-to-end connection, and decreasing it allows application to fail faster. By default, the parameter is 0, which makes the connection use the system default, and follows a logic close to the keepalive parameters in its handling. When connecting through a Unix-socket domain, the parameters have no effect. Author: Ryohei Nagaura Reviewed-by: Fabien Coelho, Robert Haas, Kyotaro Horiguchi, Kirk Jamison, Mikalai Keida, Takayuki Tsunakawa, Andrei Yahorau Discussion: https://postgr.es/m/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04
2019-04-06 08:23:37 +02:00
/*
* Set the TCP user timeout.
*/
static int
setTCPUserTimeout(PGconn *conn)
{
int timeout;
if (conn->pgtcp_user_timeout == NULL)
return 1;
if (!parse_int_param(conn->pgtcp_user_timeout, &timeout, conn,
"tcp_user_timeout"))
return 0;
if (timeout < 0)
timeout = 0;
#ifdef TCP_USER_TIMEOUT
if (setsockopt(conn->sock, IPPROTO_TCP, TCP_USER_TIMEOUT,
(char *) &timeout, sizeof(timeout)) < 0)
{
char sebuf[256];
appendPQExpBuffer(&conn->errorMessage,
Factor out system call names from error messages Instead, put them in via a format placeholder. This reduces the number of distinct translatable messages and also reduces the chances of typos during translation. We already did this for the system call arguments in a number of cases, so this is just the same thing taken a bit further. Discussion: https://www.postgresql.org/message-id/flat/92d6f545-5102-65d8-3c87-489f71ea0a37%40enterprisedb.com
2021-04-23 14:18:11 +02:00
libpq_gettext("%s(%s) failed: %s\n"),
"setsockopt",
Add support TCP user timeout in libpq and the backend server Similarly to the set of parameters for keepalive, a connection parameter for libpq is added as well as a backend GUC, called tcp_user_timeout. Increasing the TCP user timeout is useful to allow a connection to survive extended periods without end-to-end connection, and decreasing it allows application to fail faster. By default, the parameter is 0, which makes the connection use the system default, and follows a logic close to the keepalive parameters in its handling. When connecting through a Unix-socket domain, the parameters have no effect. Author: Ryohei Nagaura Reviewed-by: Fabien Coelho, Robert Haas, Kyotaro Horiguchi, Kirk Jamison, Mikalai Keida, Takayuki Tsunakawa, Andrei Yahorau Discussion: https://postgr.es/m/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04
2019-04-06 08:23:37 +02:00
"TCP_USER_TIMEOUT",
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
return 0;
}
#endif
return 1;
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/* ----------
* connectDBStart -
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
* Begin the process of making a connection to the backend.
*
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* Returns 1 if successful, 0 if not.
* ----------
*/
static int
connectDBStart(PGconn *conn)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
if (!conn)
return 0;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Add positive defense against trying to connect when the connection option state hasn't been fully set up. This is possible via PQreset() and might occur in other code paths too, so a state flag seems the most robust solution. Per report from Arturs Zoldners.
2006-02-13 23:33:57 +01:00
if (!conn->options_valid)
goto connect_errReturn;
Install a check for mis-linking of src/port and src/common functions. On ELF-based platforms (and maybe others?) it's possible for a shared library, when dynamically loaded into the backend, to call the backend versions of src/port and src/common functions rather than the frontend versions that are actually linked into the shlib. This is definitely not what we want, because the frontend versions often behave slightly differently. Up to now it's been "slight" enough that nobody noticed; but with the addition of SCRAM support functions in src/common, we're observing crashes due to the difference between palloc and malloc memory allocation rules, as reported in bug #15367 from Jeremy Evans. The purpose of this patch is to create a direct test for this type of mis-linking, so that we know whether any given platform requires extra measures to prevent using the wrong functions. If the test fails, it will lead to connection failures in the contrib/postgres_fdw regression test. At the moment, *BSD platforms using ELF format are known to have the problem and can be expected to fail; but we need to know whether anything else does, and we need a reliable ongoing check for future platforms. Actually fixing the problem will be the subject of later commit(s). Discussion: https://postgr.es/m/153626613985.23143.4743626885618266803@wrigleys.postgresql.org
2018-09-09 18:23:23 +02:00
/*
* Check for bad linking to backend-internal versions of src/common
* functions (see comments in link-canary.c for the reason we need this).
* Nobody but developers should see this message, so we don't bother
* translating it.
*/
if (!pg_link_canary_is_frontend())
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(&conn->errorMessage,
"libpq is incorrectly linked to backend functions\n");
Install a check for mis-linking of src/port and src/common functions. On ELF-based platforms (and maybe others?) it's possible for a shared library, when dynamically loaded into the backend, to call the backend versions of src/port and src/common functions rather than the frontend versions that are actually linked into the shlib. This is definitely not what we want, because the frontend versions often behave slightly differently. Up to now it's been "slight" enough that nobody noticed; but with the addition of SCRAM support functions in src/common, we're observing crashes due to the difference between palloc and malloc memory allocation rules, as reported in bug #15367 from Jeremy Evans. The purpose of this patch is to create a direct test for this type of mis-linking, so that we know whether any given platform requires extra measures to prevent using the wrong functions. If the test fails, it will lead to connection failures in the contrib/postgres_fdw regression test. At the moment, *BSD platforms using ELF format are known to have the problem and can be expected to fail; but we need to know whether anything else does, and we need a reliable ongoing check for future platforms. Actually fixing the problem will be the subject of later commit(s). Discussion: https://postgr.es/m/153626613985.23143.4743626885618266803@wrigleys.postgresql.org
2018-09-09 18:23:23 +02:00
goto connect_errReturn;
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/* Ensure our buffers are empty */
conn->inStart = conn->inCursor = conn->inEnd = 0;
conn->outCount = 0;
Fix some of the breakage from the IPV6 patch.
2003-02-14 02:24:26 +01:00
/*
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
* Set up to try to connect to the first host. (Setting whichhost = -1 is
* a bit of a cheat, but PQconnectPoll will advance it to 0 before
* anything else looks at it.)
Fix some of the breakage from the IPV6 patch.
2003-02-14 02:24:26 +01:00
*/
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->whichhost = -1;
conn->try_next_addr = false;
conn->try_next_host = true;
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
conn->status = CONNECTION_NEEDED;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/* Also reset the target_server_type state if needed */
if (conn->target_server_type == SERVER_TYPE_PREFER_STANDBY_PASS2)
conn->target_server_type = SERVER_TYPE_PREFER_STANDBY;
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/*
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
* The code for processing CONNECTION_NEEDED state is in PQconnectPoll(),
* so that it can easily be re-executed if needed again during the
* asynchronous startup process. However, we must run it once here,
* because callers expect a success return from this routine to mean that
* we are in PGRES_POLLING_WRITING connection state.
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
*/
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
if (PQconnectPoll(conn) == PGRES_POLLING_WRITING)
return 1;
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
connect_errReturn:
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/*
* If we managed to open a socket, close it immediately rather than
* waiting till PQfinish. (The application cannot have gotten the socket
* from PQsocket yet, so this doesn't risk breaking anything.)
*/
Fix unwanted flushing of libpq's input buffer when socket EOF is seen. In commit 210eb9b743c0645d I centralized libpq's logic for closing down the backend communication socket, and made the new pqDropConnection routine always reset the I/O buffers to empty. Many of the call sites previously had not had such code, and while that amounted to an oversight in some cases, there was one place where it was intentional and necessary *not* to flush the input buffer: pqReadData should never cause that to happen, since we probably still want to process whatever data we read. This is the true cause of the problem Robert was attempting to fix in c3e7c24a1d60dc6a, namely that libpq no longer reported the backend's final ERROR message before reporting "server closed the connection unexpectedly". But that only accidentally fixed it, by invoking parseInput before the input buffer got flushed; and very likely there are timing scenarios where we'd still lose the message before processing it. To fix, pass a flag to pqDropConnection to tell it whether to flush the input buffer or not. On review I think flushing is actually correct for every other call site. Back-patch to 9.3 where the problem was introduced. In HEAD, also improve the comments added by c3e7c24a1d60dc6a.
2015-11-12 19:03:52 +01:00
pqDropConnection(conn, true);
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
conn->status = CONNECTION_BAD;
return 0;
}
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove some unneeded dashes from libpq comments.
2001-08-17 17:11:15 +02:00
/*
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* connectDBComplete
*
* Block and complete a connection.
*
* Returns 1 on success, 0 on failure.
*/
static int
connectDBComplete(PGconn *conn)
{
Sigh, I'm an idiot ... I broke the async startup logic a couple days ago, by creating a race condition. It wasn't waiting for select() to say write-ready immediately after connect, which meant that you might get an unhelpful 'broken pipe' error message if connect failed, rather than the intended error message.
2000-01-16 22:18:52 +01:00
PostgresPollingStatusType flag = PGRES_POLLING_WRITING;
pgindent fe-connect.c --- done to make IPv6 patch easier to apply.
2002-12-19 20:30:24 +01:00
time_t finish_time = ((time_t) -1);
libpq: Try next host if one of them times out. If one host in a multi-host connection string times out, move on to the next specified host instead of giving up entirely. Takayuki Tsunakawa, reviewed by Michael Paquier. I added a minor adjustment to the documentation. Discussion: http://postgr.es/m/0A3221C70F24FB45833433255569204D1F6F42F5@G01JPEXMBYT05
2017-05-19 22:19:51 +02:00
int timeout = 0;
Fix libpq's implementation of per-host connection timeouts. Commit 5f374fe7a attempted to turn the connect_timeout from an overall maximum time limit into a per-host limit, but it didn't do a great job of that. The timer would only get restarted if we actually detected timeout within connectDBComplete(), not if we changed our attention to a new host for some other reason. In that case the old timeout continued to run, possibly causing a premature timeout failure for the new host. Fix that, and also tweak the logic so that if we do get a timeout, we advance to the next available IP address, not to the next host name. There doesn't seem to be a good reason to assume that all the IP addresses supplied for a given host name will necessarily fail the same way as the current one. Moreover, this conforms better to the admittedly-vague documentation statement that the timeout is "per connection attempt". I changed that to "per host name or IP address" to be clearer. (Note that reconnections to the same server, such as for switching protocol version or SSL status, don't get their own separate timeout; that was true before and remains so.) Also clarify documentation about the interpretation of connect_timeout values less than 2. This seems like a bug, so back-patch to v10 where this logic came in. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/5735.1533828184@sss.pgh.pa.us
2018-08-13 19:07:52 +02:00
int last_whichhost = -2; /* certainly different from whichhost */
struct addrinfo *last_addr_cur = NULL;
Add libpq connection timeout parameter. Denis A Ustimenko
2002-08-17 14:33:18 +02:00
Sigh, I'm an idiot ... I broke the async startup logic a couple days ago, by creating a race condition. It wasn't waiting for select() to say write-ready immediately after connect, which meant that you might get an unhelpful 'broken pipe' error message if connect failed, rather than the intended error message.
2000-01-16 22:18:52 +01:00
if (conn == NULL || conn->status == CONNECTION_BAD)
return 0;
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
Cleanup of libpq connection timeout code.
2002-08-27 16:49:52 +02:00
/*
Code review for connection timeout patch. Avoid unportable assumption that tv_sec is signed; return a useful error message on timeout failure; honor PGCONNECT_TIMEOUT environment variable in PQsetdbLogin; make code obey documentation statement that timeout=0 means no timeout.
2002-10-25 01:35:55 +02:00
* Set up a time limit, if connect_timeout isn't zero.
Cleanup of libpq connection timeout code.
2002-08-27 16:49:52 +02:00
*/
if (conn->connect_timeout != NULL)
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
{
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
if (!parse_int_param(conn->connect_timeout, &timeout, conn,
"connect_timeout"))
Fix error reporting of connect_timeout in libpq for value parsing The logic was correctly detecting a parsing failure, but the parsing error did not get reported back to the client properly. Reported-by: Ed Morley Author: Lars Kanis Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de Backpatch-through: 12
2019-10-21 04:39:15 +02:00
{
/* mark the connection as bad to report the parsing failure */
conn->status = CONNECTION_BAD;
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
return 0;
Fix error reporting of connect_timeout in libpq for value parsing The logic was correctly detecting a parsing failure, but the parsing error did not get reported back to the client properly. Reported-by: Ed Morley Author: Lars Kanis Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de Backpatch-through: 12
2019-10-21 04:39:15 +02:00
}
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
Code review for connection timeout patch. Avoid unportable assumption that tv_sec is signed; return a useful error message on timeout failure; honor PGCONNECT_TIMEOUT environment variable in PQsetdbLogin; make code obey documentation statement that timeout=0 means no timeout.
2002-10-25 01:35:55 +02:00
if (timeout > 0)
Cleanup of libpq connection timeout code.
2002-08-27 16:49:52 +02:00
{
pgindent fe-connect.c --- done to make IPv6 patch easier to apply.
2002-12-19 20:30:24 +01:00
/*
Fix libpq's implementation of per-host connection timeouts. Commit 5f374fe7a attempted to turn the connect_timeout from an overall maximum time limit into a per-host limit, but it didn't do a great job of that. The timer would only get restarted if we actually detected timeout within connectDBComplete(), not if we changed our attention to a new host for some other reason. In that case the old timeout continued to run, possibly causing a premature timeout failure for the new host. Fix that, and also tweak the logic so that if we do get a timeout, we advance to the next available IP address, not to the next host name. There doesn't seem to be a good reason to assume that all the IP addresses supplied for a given host name will necessarily fail the same way as the current one. Moreover, this conforms better to the admittedly-vague documentation statement that the timeout is "per connection attempt". I changed that to "per host name or IP address" to be clearer. (Note that reconnections to the same server, such as for switching protocol version or SSL status, don't get their own separate timeout; that was true before and remains so.) Also clarify documentation about the interpretation of connect_timeout values less than 2. This seems like a bug, so back-patch to v10 where this logic came in. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/5735.1533828184@sss.pgh.pa.us
2018-08-13 19:07:52 +02:00
* Rounding could cause connection to fail unexpectedly quickly;
* to prevent possibly waiting hardly-at-all, insist on at least
* two seconds.
pgindent fe-connect.c --- done to make IPv6 patch easier to apply.
2002-12-19 20:30:24 +01:00
*/
Code review for connection timeout patch. Avoid unportable assumption that tv_sec is signed; return a useful error message on timeout failure; honor PGCONNECT_TIMEOUT environment variable in PQsetdbLogin; make code obey documentation statement that timeout=0 means no timeout.
2002-10-25 01:35:55 +02:00
if (timeout < 2)
timeout = 2;
Cleanup of libpq connection timeout code.
2002-08-27 16:49:52 +02:00
}
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
else /* negative means 0 */
timeout = 0;
Cleanup of libpq connection timeout code.
2002-08-27 16:49:52 +02:00
}
Code review for connection timeout patch. Avoid unportable assumption that tv_sec is signed; return a useful error message on timeout failure; honor PGCONNECT_TIMEOUT environment variable in PQsetdbLogin; make code obey documentation statement that timeout=0 means no timeout.
2002-10-25 01:35:55 +02:00
for (;;)
Cleanup of libpq connection timeout code.
2002-08-27 16:49:52 +02:00
{
libpq: Try next host if one of them times out. If one host in a multi-host connection string times out, move on to the next specified host instead of giving up entirely. Takayuki Tsunakawa, reviewed by Michael Paquier. I added a minor adjustment to the documentation. Discussion: http://postgr.es/m/0A3221C70F24FB45833433255569204D1F6F42F5@G01JPEXMBYT05
2017-05-19 22:19:51 +02:00
int ret = 0;
Fix libpq's implementation of per-host connection timeouts. Commit 5f374fe7a attempted to turn the connect_timeout from an overall maximum time limit into a per-host limit, but it didn't do a great job of that. The timer would only get restarted if we actually detected timeout within connectDBComplete(), not if we changed our attention to a new host for some other reason. In that case the old timeout continued to run, possibly causing a premature timeout failure for the new host. Fix that, and also tweak the logic so that if we do get a timeout, we advance to the next available IP address, not to the next host name. There doesn't seem to be a good reason to assume that all the IP addresses supplied for a given host name will necessarily fail the same way as the current one. Moreover, this conforms better to the admittedly-vague documentation statement that the timeout is "per connection attempt". I changed that to "per host name or IP address" to be clearer. (Note that reconnections to the same server, such as for switching protocol version or SSL status, don't get their own separate timeout; that was true before and remains so.) Also clarify documentation about the interpretation of connect_timeout values less than 2. This seems like a bug, so back-patch to v10 where this logic came in. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/5735.1533828184@sss.pgh.pa.us
2018-08-13 19:07:52 +02:00
/*
* (Re)start the connect_timeout timer if it's active and we are
* considering a different host than we were last time through. If
* we've already succeeded, though, needn't recalculate.
*/
if (flag != PGRES_POLLING_OK &&
timeout > 0 &&
(conn->whichhost != last_whichhost ||
conn->addr_cur != last_addr_cur))
{
finish_time = time(NULL) + timeout;
last_whichhost = conn->whichhost;
last_addr_cur = conn->addr_cur;
}
Sigh, I'm an idiot ... I broke the async startup logic a couple days ago, by creating a race condition. It wasn't waiting for select() to say write-ready immediately after connect, which meant that you might get an unhelpful 'broken pipe' error message if connect failed, rather than the intended error message.
2000-01-16 22:18:52 +01:00
/*
* Wait, if necessary. Note that the initial state (just after
* PQconnectStart) is to wait for the socket to select for writing.
*/
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
switch (flag)
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
{
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
case PGRES_POLLING_OK:
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
return 1; /* success! */
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
case PGRES_POLLING_READING:
libpq: Try next host if one of them times out. If one host in a multi-host connection string times out, move on to the next specified host instead of giving up entirely. Takayuki Tsunakawa, reviewed by Michael Paquier. I added a minor adjustment to the documentation. Discussion: http://postgr.es/m/0A3221C70F24FB45833433255569204D1F6F42F5@G01JPEXMBYT05
2017-05-19 22:19:51 +02:00
ret = pqWaitTimed(1, 0, conn, finish_time);
if (ret == -1)
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
{
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/* hard failure, eg select() problem, aborts everything */
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
conn->status = CONNECTION_BAD;
return 0;
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
break;
case PGRES_POLLING_WRITING:
libpq: Try next host if one of them times out. If one host in a multi-host connection string times out, move on to the next specified host instead of giving up entirely. Takayuki Tsunakawa, reviewed by Michael Paquier. I added a minor adjustment to the documentation. Discussion: http://postgr.es/m/0A3221C70F24FB45833433255569204D1F6F42F5@G01JPEXMBYT05
2017-05-19 22:19:51 +02:00
ret = pqWaitTimed(0, 1, conn, finish_time);
if (ret == -1)
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
{
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/* hard failure, eg select() problem, aborts everything */
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
conn->status = CONNECTION_BAD;
return 0;
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
break;
default:
/* Just in case we failed to set it in PQconnectPoll */
conn->status = CONNECTION_BAD;
return 0;
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
}
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
libpq: Try next host if one of them times out. If one host in a multi-host connection string times out, move on to the next specified host instead of giving up entirely. Takayuki Tsunakawa, reviewed by Michael Paquier. I added a minor adjustment to the documentation. Discussion: http://postgr.es/m/0A3221C70F24FB45833433255569204D1F6F42F5@G01JPEXMBYT05
2017-05-19 22:19:51 +02:00
if (ret == 1) /* connect_timeout elapsed */
{
/*
Fix libpq's implementation of per-host connection timeouts. Commit 5f374fe7a attempted to turn the connect_timeout from an overall maximum time limit into a per-host limit, but it didn't do a great job of that. The timer would only get restarted if we actually detected timeout within connectDBComplete(), not if we changed our attention to a new host for some other reason. In that case the old timeout continued to run, possibly causing a premature timeout failure for the new host. Fix that, and also tweak the logic so that if we do get a timeout, we advance to the next available IP address, not to the next host name. There doesn't seem to be a good reason to assume that all the IP addresses supplied for a given host name will necessarily fail the same way as the current one. Moreover, this conforms better to the admittedly-vague documentation statement that the timeout is "per connection attempt". I changed that to "per host name or IP address" to be clearer. (Note that reconnections to the same server, such as for switching protocol version or SSL status, don't get their own separate timeout; that was true before and remains so.) Also clarify documentation about the interpretation of connect_timeout values less than 2. This seems like a bug, so back-patch to v10 where this logic came in. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/5735.1533828184@sss.pgh.pa.us
2018-08-13 19:07:52 +02:00
* Give up on current server/address, try the next one.
libpq: Try next host if one of them times out. If one host in a multi-host connection string times out, move on to the next specified host instead of giving up entirely. Takayuki Tsunakawa, reviewed by Michael Paquier. I added a minor adjustment to the documentation. Discussion: http://postgr.es/m/0A3221C70F24FB45833433255569204D1F6F42F5@G01JPEXMBYT05
2017-05-19 22:19:51 +02:00
*/
Fix libpq's implementation of per-host connection timeouts. Commit 5f374fe7a attempted to turn the connect_timeout from an overall maximum time limit into a per-host limit, but it didn't do a great job of that. The timer would only get restarted if we actually detected timeout within connectDBComplete(), not if we changed our attention to a new host for some other reason. In that case the old timeout continued to run, possibly causing a premature timeout failure for the new host. Fix that, and also tweak the logic so that if we do get a timeout, we advance to the next available IP address, not to the next host name. There doesn't seem to be a good reason to assume that all the IP addresses supplied for a given host name will necessarily fail the same way as the current one. Moreover, this conforms better to the admittedly-vague documentation statement that the timeout is "per connection attempt". I changed that to "per host name or IP address" to be clearer. (Note that reconnections to the same server, such as for switching protocol version or SSL status, don't get their own separate timeout; that was true before and remains so.) Also clarify documentation about the interpretation of connect_timeout values less than 2. This seems like a bug, so back-patch to v10 where this logic came in. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/5735.1533828184@sss.pgh.pa.us
2018-08-13 19:07:52 +02:00
conn->try_next_addr = true;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->status = CONNECTION_NEEDED;
libpq: Try next host if one of them times out. If one host in a multi-host connection string times out, move on to the next specified host instead of giving up entirely. Takayuki Tsunakawa, reviewed by Michael Paquier. I added a minor adjustment to the documentation. Discussion: http://postgr.es/m/0A3221C70F24FB45833433255569204D1F6F42F5@G01JPEXMBYT05
2017-05-19 22:19:51 +02:00
}
Sigh, I'm an idiot ... I broke the async startup logic a couple days ago, by creating a race condition. It wasn't waiting for select() to say write-ready immediately after connect, which meant that you might get an unhelpful 'broken pipe' error message if connect failed, rather than the intended error message.
2000-01-16 22:18:52 +01:00
/*
* Now try to advance the state machine.
*/
flag = PQconnectPoll(conn);
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
}
/* ----------------
* PQconnectPoll
*
* Poll an asynchronous connection.
*
* Returns a PostgresPollingStatusType.
The attached patch implements the password packet length sanity check (using an elog(LOG) ), as well as includes a few more comment fixes. Neil Conway
2002-08-27 18:21:51 +02:00
* Before calling this function, use select(2) to determine when data
* has arrived..
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
*
* You must call PQfinish whether or not this fails.
*
* This function and PQconnectStart are intended to allow connections to be
* made without blocking the execution of your program on remote I/O. However,
* there are a number of caveats:
*
* o If you call PQtrace, ensure that the stream object into which you trace
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
* will not block.
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* o If you do not supply an IP address for the remote host (i.e. you
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
* supply a host name instead) then PQconnectStart will block on
Remove configure probe for gethostbyname_r. It was only used by src/port/getaddrinfo.c, removed by the previous commit. Discussion: https://postgr.es/m/CA%2BhUKGJFLPCtAC58EAimF6a6GPw30TU_59FUY%3DGWB_kC%3DJEmVQ%40mail.gmail.com
2022-08-13 23:57:48 +02:00
* getaddrinfo. You will be fine if using Unix sockets (i.e. by
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
* supplying neither a host name nor a host address).
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* o If your backend wants to use Kerberos authentication then you must
* supply both a host name and a host address, otherwise this function
* may block on gethostname.
*
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
* ----------------
*/
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
PostgresPollingStatusType
PQconnectPoll(PGconn *conn)
{
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
bool reset_connection_state_machine = false;
bool need_new_connection = false;
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
PGresult *res;
Incorporate strerror_r() into src/port/snprintf.c, too. This provides the features that used to exist in useful_strerror() for users of strerror_r(), too. Also, standardize on the GNU convention that strerror_r returns a char pointer that may not be NULL. I notice that libpq's win32.c contains a variant version of strerror_r that probably ought to be folded into strerror.c. But lacking a Windows environment, I should leave that to somebody else. Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
2018-09-26 18:35:57 +02:00
char sebuf[PG_STRERROR_R_BUFLEN];
Avoid extra system calls to block SIGPIPE if the platform provides either sockopt(SO_NOSIGPIPE) or the MSG_NOSIGNAL flag to send(). We assume these features are available if (1) the symbol is defined at compile time and (2) the kernel doesn't reject the call at runtime. It might turn out that there are some platforms where (1) and (2) are true and yet the signal isn't really blocked, in which case applications would die on server crash. If that sort of thing gets reported, then we'll have to add additional defenses of some kind. Jeremy Kerr
2009-07-24 19:58:31 +02:00
int optval;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
if (conn == NULL)
return PGRES_POLLING_FAILED;
/* Get the new data */
switch (conn->status)
{
/*
* We really shouldn't have been polled in these two cases, but we
* can handle it.
*/
case CONNECTION_BAD:
return PGRES_POLLING_FAILED;
case CONNECTION_OK:
return PGRES_POLLING_OK;
/* These are reading states */
case CONNECTION_AWAITING_RESPONSE:
case CONNECTION_AUTH_OK:
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
case CONNECTION_CHECK_WRITABLE:
case CONNECTION_CONSUME:
case CONNECTION_CHECK_STANDBY:
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
{
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/* Load waiting data */
int n = pqReadData(conn);
if (n < 0)
goto error_return;
if (n == 0)
return PGRES_POLLING_READING;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
break;
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/* These are writing states, so we just proceed. */
case CONNECTION_STARTED:
case CONNECTION_MADE:
break;
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/* Special cases: proceed without waiting. */
case CONNECTION_SSL_STARTUP:
case CONNECTION_NEEDED:
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
case CONNECTION_GSS_STARTUP:
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
case CONNECTION_CHECK_TARGET:
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
break;
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
default:
Replace appendPQExpBuffer(..., <constant>) with appendPQExpBufferStr Arguably makes the code a bit more readable, and might give a small performance gain. David Rowley
2013-11-18 17:29:01 +01:00
appendPQExpBufferStr(&conn->errorMessage,
NLS for libpq. Clean up the message formats and change the documentation accordingly.
2001-07-15 15:45:04 +02:00
libpq_gettext("invalid connection state, probably indicative of memory corruption\n"));
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
goto error_return;
}
keep_going: /* We will come back to here until there is
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
* nothing left to do. */
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/* Time to advance to next address, or next host if no more addresses? */
if (conn->try_next_addr)
{
if (conn->addr_cur && conn->addr_cur->ai_next)
{
conn->addr_cur = conn->addr_cur->ai_next;
reset_connection_state_machine = true;
}
else
conn->try_next_host = true;
conn->try_next_addr = false;
}
/* Time to advance to next connhost[] entry? */
if (conn->try_next_host)
{
In libpq, don't look up all the hostnames at once. Historically, we looked up the target hostname in connectDBStart, so that PQconnectPoll did not need to do DNS name resolution. The patches that added multiple-target-host support to libpq preserved this division of labor; but it's really nonsensical now, because it means that if any one of the target hosts fails to resolve in DNS, the connection fails. That negates the no-single-point-of-failure goal of the feature. Additionally, DNS lookups aren't exactly cheap, but the code did them all even if the first connection attempt succeeds. Hence, rearrange so that PQconnectPoll does the lookups, and only looks up a hostname when it's time to try that host. This does mean that PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid that, you should be using hostaddr, as the documentation has always specified. It seems fairly unlikely that any applications would really care whether the lookup occurs inside PQconnectStart or PQconnectPoll. In addition to calling out that fact explicitly, do some other minor wordsmithing in the docs around the multiple-target-host feature. Since this seems like a bug in the multiple-target-host feature, backpatch to v10 where that was introduced. In the back branches, avoid moving any existing fields of struct pg_conn, just in case any third-party code is looking into that struct. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
2018-08-23 22:39:19 +02:00
pg_conn_host *ch;
struct addrinfo hint;
int thisport;
int ret;
char portstr[MAXPGPATH];
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
if (conn->whichhost + 1 < conn->nconnhost)
conn->whichhost++;
else
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
{
/*
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
* Oops, no more hosts.
*
* If we are trying to connect in "prefer-standby" mode, then drop
* the standby requirement and start over.
*
* Otherwise, an appropriate error message is already set up, so
* we just need to set the right status.
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
*/
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
if (conn->target_server_type == SERVER_TYPE_PREFER_STANDBY &&
conn->nconnhost > 0)
{
conn->target_server_type = SERVER_TYPE_PREFER_STANDBY_PASS2;
conn->whichhost = 0;
}
else
goto error_return;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
}
In libpq, don't look up all the hostnames at once. Historically, we looked up the target hostname in connectDBStart, so that PQconnectPoll did not need to do DNS name resolution. The patches that added multiple-target-host support to libpq preserved this division of labor; but it's really nonsensical now, because it means that if any one of the target hosts fails to resolve in DNS, the connection fails. That negates the no-single-point-of-failure goal of the feature. Additionally, DNS lookups aren't exactly cheap, but the code did them all even if the first connection attempt succeeds. Hence, rearrange so that PQconnectPoll does the lookups, and only looks up a hostname when it's time to try that host. This does mean that PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid that, you should be using hostaddr, as the documentation has always specified. It seems fairly unlikely that any applications would really care whether the lookup occurs inside PQconnectStart or PQconnectPoll. In addition to calling out that fact explicitly, do some other minor wordsmithing in the docs around the multiple-target-host feature. Since this seems like a bug in the multiple-target-host feature, backpatch to v10 where that was introduced. In the back branches, avoid moving any existing fields of struct pg_conn, just in case any third-party code is looking into that struct. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
2018-08-23 22:39:19 +02:00
/* Drop any address info for previous host */
release_conn_addrinfo(conn);
/*
* Look up info for the new host. On failure, log the problem in
* conn->errorMessage, then loop around to try the next host. (Note
* we don't clear try_next_host until we've succeeded.)
*/
ch = &conn->connhost[conn->whichhost];
/* Initialize hint structure */
MemSet(&hint, 0, sizeof(hint));
hint.ai_socktype = SOCK_STREAM;
conn->addrlist_family = hint.ai_family = AF_UNSPEC;
/* Figure out the port number we're going to use. */
if (ch->port == NULL || ch->port[0] == '\0')
thisport = DEF_PGPORT;
else
{
Parse more strictly integer parameters from connection strings in libpq The following parameters have been parsed in lossy ways when specified in a connection string processed by libpq: - connect_timeout - keepalives - keepalives_count - keepalives_idle - keepalives_interval - port Overflowing values or the presence of incorrect characters were not properly checked, leading to libpq trying to use such values and fail with unhelpful error messages. This commit hardens the parsing of those parameters so as it is possible to find easily incorrect values. Author: Fabien Coelho Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/alpine.DEB.2.21.1808171206180.20841@lancre
2018-09-11 23:46:01 +02:00
if (!parse_int_param(ch->port, &thisport, conn, "port"))
goto error_return;
In libpq, don't look up all the hostnames at once. Historically, we looked up the target hostname in connectDBStart, so that PQconnectPoll did not need to do DNS name resolution. The patches that added multiple-target-host support to libpq preserved this division of labor; but it's really nonsensical now, because it means that if any one of the target hosts fails to resolve in DNS, the connection fails. That negates the no-single-point-of-failure goal of the feature. Additionally, DNS lookups aren't exactly cheap, but the code did them all even if the first connection attempt succeeds. Hence, rearrange so that PQconnectPoll does the lookups, and only looks up a hostname when it's time to try that host. This does mean that PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid that, you should be using hostaddr, as the documentation has always specified. It seems fairly unlikely that any applications would really care whether the lookup occurs inside PQconnectStart or PQconnectPoll. In addition to calling out that fact explicitly, do some other minor wordsmithing in the docs around the multiple-target-host feature. Since this seems like a bug in the multiple-target-host feature, backpatch to v10 where that was introduced. In the back branches, avoid moving any existing fields of struct pg_conn, just in case any third-party code is looking into that struct. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
2018-08-23 22:39:19 +02:00
if (thisport < 1 || thisport > 65535)
{
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("invalid port number: \"%s\"\n"),
ch->port);
goto keep_going;
}
}
snprintf(portstr, sizeof(portstr), "%d", thisport);
/* Use pg_getaddrinfo_all() to resolve the address */
switch (ch->type)
{
case CHT_HOST_NAME:
ret = pg_getaddrinfo_all(ch->host, portstr, &hint,
&conn->addrlist);
if (ret || !conn->addrlist)
{
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("could not translate host name \"%s\" to address: %s\n"),
ch->host, gai_strerror(ret));
goto keep_going;
}
break;
case CHT_HOST_ADDRESS:
hint.ai_flags = AI_NUMERICHOST;
ret = pg_getaddrinfo_all(ch->hostaddr, portstr, &hint,
&conn->addrlist);
if (ret || !conn->addrlist)
{
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("could not parse network address \"%s\": %s\n"),
ch->hostaddr, gai_strerror(ret));
goto keep_going;
}
break;
case CHT_UNIX_SOCKET:
conn->addrlist_family = hint.ai_family = AF_UNIX;
UNIXSOCK_PATH(portstr, thisport, ch->host);
if (strlen(portstr) >= UNIXSOCK_PATH_BUFLEN)
{
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("Unix-domain socket path \"%s\" is too long (maximum %d bytes)\n"),
portstr,
(int) (UNIXSOCK_PATH_BUFLEN - 1));
goto keep_going;
}
/*
* NULL hostname tells pg_getaddrinfo_all to parse the service
* name as a Unix-domain socket path.
*/
ret = pg_getaddrinfo_all(NULL, portstr, &hint,
&conn->addrlist);
if (ret || !conn->addrlist)
{
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("could not translate Unix-domain socket path \"%s\" to address: %s\n"),
portstr, gai_strerror(ret));
goto keep_going;
}
break;
}
/* OK, scan this addrlist for a working server address */
conn->addr_cur = conn->addrlist;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
reset_connection_state_machine = true;
conn->try_next_host = false;
}
/* Reset connection state machine? */
if (reset_connection_state_machine)
{
/*
* (Re) initialize our connection control variables for a set of
* connection attempts to a single server address. These variables
* must persist across individual connection attempts, but we must
* reset them when we start to consider a new server.
*/
conn->pversion = PG_PROTOCOL(3, 0);
conn->send_appname = true;
#ifdef USE_SSL
/* initialize these values based on SSL mode */
conn->allow_ssl_try = (conn->sslmode[0] != 'd'); /* "disable" */
conn->wait_ssl_try = (conn->sslmode[0] == 'a'); /* "allow" */
#endif
Fix bugs in libpq's management of GSS encryption state. GSS-related resources should be cleaned up in pqDropConnection, not freePGconn, else the wrong things happen when resetting a connection or trying to switch to a different server. It's also critical to reset conn->gssenc there. During connection setup, initialize conn->try_gss at the correct place, else switching to a different server won't work right. Remove now-redundant cleanup of GSS resources around one (and, for some reason, only one) pqDropConnection call in connectDBStart. Per report from Kyotaro Horiguchi that psql would freeze up, rather than successfully resetting a GSS-encrypted connection after a server restart. This is YA oversight in commit b0b39f72b, so back-patch to v12. Discussion: https://postgr.es/m/20200710.173803.435804731896516388.horikyota.ntt@gmail.com
2020-07-13 17:57:55 +02:00
#ifdef ENABLE_GSS
conn->try_gss = (conn->gssencmode[0] != 'd'); /* "disable" */
#endif
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
reset_connection_state_machine = false;
need_new_connection = true;
}
/* Force a new connection (perhaps to the same server as before)? */
if (need_new_connection)
{
/* Drop any existing connection */
pqDropConnection(conn, true);
/* Reset all state obtained from old server */
pqDropServerData(conn);
/* Drop any PGresult we might have, too */
conn->asyncStatus = PGASYNC_IDLE;
conn->xactStatus = PQTRANS_IDLE;
Implement pipeline mode in libpq Pipeline mode in libpq lets an application avoid the Sync messages in the FE/BE protocol that are implicit in the old libpq API after each query. The application can then insert Sync at its leisure with a new libpq function PQpipelineSync. This can lead to substantial reductions in query latency. Co-authored-by: Craig Ringer <craig.ringer@enterprisedb.com> Co-authored-by: Matthieu Garrigues <matthieu.garrigues@gmail.com> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Aya Iwata <iwata.aya@jp.fujitsu.com> Reviewed-by: Daniel Vérité <daniel@manitou-mail.org> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Kirk Jamison <k.jamison@fujitsu.com> Reviewed-by: Michael Paquier <michael.paquier@gmail.com> Reviewed-by: Nikhil Sontakke <nikhils@2ndquadrant.com> Reviewed-by: Vaishnavi Prabakaran <VaishnaviP@fast.au.fujitsu.com> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Discussion: https://postgr.es/m/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com Discussion: https://postgr.es/m/CAJkzx4T5E-2cQe3dtv2R78dYFvz+in8PY7A8MArvLhs_pg75gg@mail.gmail.com
2021-03-15 22:13:42 +01:00
conn->pipelineStatus = PQ_PIPELINE_OFF;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
pqClearAsyncResult(conn);
/* Reset conn->status to put the state machine in the right state */
conn->status = CONNECTION_NEEDED;
need_new_connection = false;
}
/* Now try to advance the state machine for this connection */
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
switch (conn->status)
{
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
case CONNECTION_NEEDED:
{
/*
* Try to initiate a connection to one of the addresses
Clean up libpq's pollution of application namespace by renaming the exported routines of ip.c, md5.c, and fe-auth.c to begin with 'pg_'. Also get rid of the vestigial fe_setauthsvc/fe_getauthsvc routines altogether.
2005-10-17 18:24:20 +02:00
* returned by pg_getaddrinfo_all(). conn->addr_cur is the
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
* next one to try.
*
* The extra level of braces here is historical. It's not
* worth reindenting this whole switch case to remove 'em.
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
*/
{
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
struct addrinfo *addr_cur = conn->addr_cur;
psql: Show IP address in \conninfo When hostaddr is given, the actual IP address that psql is connected to can be totally unexpected for the given host. The more verbose output we now generate makes things clearer. Since the "host" and "hostaddr" parts of the conninfo could come from different sources (say, one of them is in the service specification or a URI-style conninfo and the other is not), this is not as silly as it may first appear. This is also definitely useful if the hostname resolves to multiple addresses. Author: Fabien Coelho Reviewed-by: Pavel Stehule, Arthur Zakirov Discussion: https://postgr.es/m/alpine.DEB.2.21.1810261532380.27686@lancre https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre
2018-11-19 18:34:12 +01:00
char host_addr[NI_MAXHOST];
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
/*
* Advance to next possible host, if we've tried all of
* the addresses for the current host.
*/
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
if (addr_cur == NULL)
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
{
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->try_next_host = true;
goto keep_going;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
}
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
/* Remember current address for possible use later */
We neglected to set conn->raddr.salen, leading to breakage of CANCEL and probably other stuff.
2003-06-20 06:09:12 +02:00
memcpy(&conn->raddr.addr, addr_cur->ai_addr,
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
addr_cur->ai_addrlen);
We neglected to set conn->raddr.salen, leading to breakage of CANCEL and probably other stuff.
2003-06-20 06:09:12 +02:00
conn->raddr.salen = addr_cur->ai_addrlen;
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
/*
* Set connip, too. Note we purposely ignore strdup
* failure; not a big problem if it fails.
*/
psql: Show IP address in \conninfo When hostaddr is given, the actual IP address that psql is connected to can be totally unexpected for the given host. The more verbose output we now generate makes things clearer. Since the "host" and "hostaddr" parts of the conninfo could come from different sources (say, one of them is in the service specification or a URI-style conninfo and the other is not), this is not as silly as it may first appear. This is also definitely useful if the hostname resolves to multiple addresses. Author: Fabien Coelho Reviewed-by: Pavel Stehule, Arthur Zakirov Discussion: https://postgr.es/m/alpine.DEB.2.21.1810261532380.27686@lancre https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre
2018-11-19 18:34:12 +01:00
if (conn->connip != NULL)
{
free(conn->connip);
conn->connip = NULL;
}
getHostaddr(conn, host_addr, NI_MAXHOST);
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
if (host_addr[0])
psql: Show IP address in \conninfo When hostaddr is given, the actual IP address that psql is connected to can be totally unexpected for the given host. The more verbose output we now generate makes things clearer. Since the "host" and "hostaddr" parts of the conninfo could come from different sources (say, one of them is in the service specification or a URI-style conninfo and the other is not), this is not as silly as it may first appear. This is also definitely useful if the hostname resolves to multiple addresses. Author: Fabien Coelho Reviewed-by: Pavel Stehule, Arthur Zakirov Discussion: https://postgr.es/m/alpine.DEB.2.21.1810261532380.27686@lancre https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre
2018-11-19 18:34:12 +01:00
conn->connip = strdup(host_addr);
Initial pgindent run for v12. This is still using the 2.0 version of pg_bsd_indent. I thought it would be good to commit this separately, so as to document the differences between 2.0 and 2.1 behavior. Discussion: https://postgr.es/m/16296.1558103386@sss.pgh.pa.us
2019-05-22 18:55:34 +02:00
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
/* Try to create the socket */
libpq: use pgsocket for socket values, for portability Previously, 'int' was used for socket values in libpq, but socket values are unsigned on Windows. This is a style correction. Initial patch and previous PGINVALID_SOCKET initial patch by Joel Jacobson, modified by me Report from PVS-Studio
2014-04-17 01:46:51 +02:00
conn->sock = socket(addr_cur->ai_family, SOCK_STREAM, 0);
if (conn->sock == PGINVALID_SOCKET)
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
{
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
int errorno = SOCK_ERRNO;
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/*
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
* Silently ignore socket() failure if we have more
* addresses to try; this reduces useless chatter in
* cases where the address list includes both IPv4 and
* IPv6 but kernel only accepts one family.
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
*/
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
if (addr_cur->ai_next != NULL ||
conn->whichhost + 1 < conn->nconnhost)
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
{
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->try_next_addr = true;
goto keep_going;
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
}
Improve new wording of libpq's connection failure messages. "connection to server so-and-so failed:" seems clearer than the previous wording "could not connect to so-and-so:" (introduced by 52a10224e), because the latter suggests a network-level connection failure. We're now prefixing this string to all types of connection failures, for instance authentication failures; so we need wording that doesn't imply a low-level error. Per discussion with Robert Haas. Discussion: https://postgr.es/m/CA+TgmobssJ6rS22dspWnu-oDxXevGmhMD8VcRBjmj-b9UDqRjw@mail.gmail.com
2021-01-21 22:10:18 +01:00
emitHostIdentityInfo(conn, host_addr);
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
libpq_gettext("could not create socket: %s\n"),
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
SOCK_STRERROR(errorno, sebuf, sizeof(sebuf)));
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
goto error_return;
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
}
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
/*
* Once we've identified a target address, all errors
* except the preceding socket()-failure case should be
Improve new wording of libpq's connection failure messages. "connection to server so-and-so failed:" seems clearer than the previous wording "could not connect to so-and-so:" (introduced by 52a10224e), because the latter suggests a network-level connection failure. We're now prefixing this string to all types of connection failures, for instance authentication failures; so we need wording that doesn't imply a low-level error. Per discussion with Robert Haas. Discussion: https://postgr.es/m/CA+TgmobssJ6rS22dspWnu-oDxXevGmhMD8VcRBjmj-b9UDqRjw@mail.gmail.com
2021-01-21 22:10:18 +01:00
* prefixed with host-identity information. (If the
* connection succeeds, the contents of conn->errorMessage
* won't matter, so this is harmless.)
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
*/
Improve new wording of libpq's connection failure messages. "connection to server so-and-so failed:" seems clearer than the previous wording "could not connect to so-and-so:" (introduced by 52a10224e), because the latter suggests a network-level connection failure. We're now prefixing this string to all types of connection failures, for instance authentication failures; so we need wording that doesn't imply a low-level error. Per discussion with Robert Haas. Discussion: https://postgr.es/m/CA+TgmobssJ6rS22dspWnu-oDxXevGmhMD8VcRBjmj-b9UDqRjw@mail.gmail.com
2021-01-21 22:10:18 +01:00
emitHostIdentityInfo(conn, host_addr);
Uniformly identify the target host in libpq connection failure reports. Prefix "could not connect to host-or-socket-path:" to all connection failure cases that occur after the socket() call, and remove the ad-hoc server identity data that was appended to a few of these messages. This should produce much more intelligible error reports in multiple-target-host situations, especially for error cases that are off the beaten track to any degree (because none of those provided any server identity info). As an example of the change, formerly a connection attempt with a bad port number such as "psql -p 12345 -h localhost,/tmp" might produce psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? Now it looks like psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? This requires adjusting a couple of regression tests to allow for variation in the contents of a connection failure message. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:03:39 +01:00
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/*
* Select socket options: no delay of outgoing data for
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
* TCP sockets, nonblock mode, close-on-exec. Try the
* next address if any of this fails.
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
*/
Remove IS_AF_UNIX macro The AF_UNIX macro was being used unprotected by HAVE_UNIX_SOCKETS, apparently since 2008. So the redirection through IS_AF_UNIX() is apparently no longer necessary. (More generally, all supported platforms are now HAVE_UNIX_SOCKETS, but even if there were a new platform in the future, it seems plausible that it would define the AF_UNIX symbol even without kernel support.) So remove the IS_AF_UNIX() macro and make the code a bit more consistent. Discussion: https://www.postgresql.org/message-id/flat/f2d26815-9832-e333-d52d-72fbc0ade896%40enterprisedb.com
2022-02-15 10:03:52 +01:00
if (addr_cur->ai_family != AF_UNIX)
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
{
if (!connectNoDelay(conn))
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
{
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/* error message already created */
conn->try_next_addr = true;
goto keep_going;
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
}
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
}
Kerberos fixes from Magnus Hagander --- in theory Kerberos 5 auth should work on Windows now. Also, rename set_noblock to pg_set_noblock; since it is included in libpq, the former name polluted application namespace.
2005-03-25 01:34:31 +01:00
if (!pg_set_noblock(conn->sock))
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
{
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
Standardize spelling of "nonblocking" Only adjusted the user-exposed messages and documentation, not all source code comments.
2013-04-19 05:35:19 +02:00
libpq_gettext("could not set socket to nonblocking mode: %s\n"),
Set the close-on-exec flag for libpq's socket to the backend, to avoid any possible problems from child programs executed by the client app. Per suggestion from Elliot Lee of Red Hat.
2004-10-21 22:23:19 +02:00
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->try_next_addr = true;
goto keep_going;
Set the close-on-exec flag for libpq's socket to the backend, to avoid any possible problems from child programs executed by the client app. Per suggestion from Elliot Lee of Red Hat.
2004-10-21 22:23:19 +02:00
}
Partially revert commit 536d47bd9d5fce8d91929bee3128fa1d08dbcc57. Per buildfarm, the "#ifdef F_SETFD" removed in that commit actually is needed on Windows, because fcntl() isn't available at all on that platform, unless using Cygwin. We could perhaps spell it more like "#ifdef HAVE_FCNTL", or "#ifndef WIN32", but it's not clear that those choices are better. It does seem that we don't need the bogus manual definition of FD_CLOEXEC, though, so keep that change. Discussion: https://postgr.es/m/26254.1492805635@sss.pgh.pa.us
2017-04-22 08:06:16 +02:00
#ifdef F_SETFD
Set the close-on-exec flag for libpq's socket to the backend, to avoid any possible problems from child programs executed by the client app. Per suggestion from Elliot Lee of Red Hat.
2004-10-21 22:23:19 +02:00
if (fcntl(conn->sock, F_SETFD, FD_CLOEXEC) == -1)
{
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
Set the close-on-exec flag for libpq's socket to the backend, to avoid any possible problems from child programs executed by the client app. Per suggestion from Elliot Lee of Red Hat.
2004-10-21 22:23:19 +02:00
libpq_gettext("could not set socket to close-on-exec mode: %s\n"),
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->try_next_addr = true;
goto keep_going;
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
}
Partially revert commit 536d47bd9d5fce8d91929bee3128fa1d08dbcc57. Per buildfarm, the "#ifdef F_SETFD" removed in that commit actually is needed on Windows, because fcntl() isn't available at all on that platform, unless using Cygwin. We could perhaps spell it more like "#ifdef HAVE_FCNTL", or "#ifndef WIN32", but it's not clear that those choices are better. It does seem that we don't need the bogus manual definition of FD_CLOEXEC, though, so keep that change. Discussion: https://postgr.es/m/26254.1492805635@sss.pgh.pa.us
2017-04-22 08:06:16 +02:00
#endif /* F_SETFD */
pgindent run.
2003-08-04 02:43:34 +02:00
Remove IS_AF_UNIX macro The AF_UNIX macro was being used unprotected by HAVE_UNIX_SOCKETS, apparently since 2008. So the redirection through IS_AF_UNIX() is apparently no longer necessary. (More generally, all supported platforms are now HAVE_UNIX_SOCKETS, but even if there were a new platform in the future, it seems plausible that it would define the AF_UNIX symbol even without kernel support.) So remove the IS_AF_UNIX() macro and make the code a bit more consistent. Discussion: https://www.postgresql.org/message-id/flat/f2d26815-9832-e333-d52d-72fbc0ade896%40enterprisedb.com
2022-02-15 10:03:52 +01:00
if (addr_cur->ai_family != AF_UNIX)
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
{
Silence compiler warning about unused variable on Windows.
2011-04-19 13:54:48 +02:00
#ifndef WIN32
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
int on = 1;
Silence compiler warning about unused variable on Windows.
2011-04-19 13:54:48 +02:00
#endif
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
int usekeepalives = useKeepalives(conn);
int err = 0;
if (usekeepalives < 0)
{
Replace appendPQExpBuffer(..., <constant>) with appendPQExpBufferStr Arguably makes the code a bit more readable, and might give a small performance gain. David Rowley
2013-11-18 17:29:01 +01:00
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("keepalives parameter must be an integer\n"));
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
err = 1;
}
else if (usekeepalives == 0)
{
/* Do nothing */
}
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
#ifndef WIN32
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
else if (setsockopt(conn->sock,
SOL_SOCKET, SO_KEEPALIVE,
(char *) &on, sizeof(on)) < 0)
{
appendPQExpBuffer(&conn->errorMessage,
Factor out system call names from error messages Instead, put them in via a format placeholder. This reduces the number of distinct translatable messages and also reduces the chances of typos during translation. We already did this for the system call arguments in a number of cases, so this is just the same thing taken a bit further. Discussion: https://www.postgresql.org/message-id/flat/92d6f545-5102-65d8-3c87-489f71ea0a37%40enterprisedb.com
2021-04-23 14:18:11 +02:00
libpq_gettext("%s(%s) failed: %s\n"),
"setsockopt",
Second try at fixing tcp_keepalives_idle option on Solaris. Buildfarm evidence shows that TCP_KEEPALIVE_THRESHOLD doesn't exist after all on Solaris < 11. This means we need to take positive action to prevent the TCP_KEEPALIVE code path from being taken on that platform. I've chosen to limit it with "&& defined(__darwin__)", since it's unclear that anyone else would follow Apple's precedent of spelling the symbol that way. Also, follow a suggestion from Michael Paquier of eliminating code duplication by defining a couple of intermediate symbols for the socket option. In passing, make some effort to reduce the number of translatable messages by replacing "setsockopt(foo) failed" with "setsockopt(%s) failed", etc, throughout the affected files. And update relevant documentation so that it doesn't claim to provide an exhaustive list of the possible socket option names. Like the previous commit (f0256c774), back-patch to all supported branches. Discussion: https://postgr.es/m/20170627163757.25161.528@wrigleys.postgresql.org
2017-06-28 18:30:16 +02:00
"SO_KEEPALIVE",
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
err = 1;
}
else if (!setKeepalivesIdle(conn)
|| !setKeepalivesInterval(conn)
|| !setKeepalivesCount(conn))
err = 1;
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
#else /* WIN32 */
Make the Windows tcp keepalive support depend on the existance of the SIO_KEEPALIVE_VALS define instead of just WIN32, since MingW doesn't support this API (yet?).
2010-07-08 18:19:50 +02:00
#ifdef SIO_KEEPALIVE_VALS
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
else if (!prepKeepalivesWin32(conn))
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
err = 1;
Make the Windows tcp keepalive support depend on the existance of the SIO_KEEPALIVE_VALS define instead of just WIN32, since MingW doesn't support this API (yet?).
2010-07-08 18:19:50 +02:00
#endif /* SIO_KEEPALIVE_VALS */
Add support for TCP keepalives on Windows, both for backend and the new libpq support.
2010-07-08 12:20:14 +02:00
#endif /* WIN32 */
Add support TCP user timeout in libpq and the backend server Similarly to the set of parameters for keepalive, a connection parameter for libpq is added as well as a backend GUC, called tcp_user_timeout. Increasing the TCP user timeout is useful to allow a connection to survive extended periods without end-to-end connection, and decreasing it allows application to fail faster. By default, the parameter is 0, which makes the connection use the system default, and follows a logic close to the keepalive parameters in its handling. When connecting through a Unix-socket domain, the parameters have no effect. Author: Ryohei Nagaura Reviewed-by: Fabien Coelho, Robert Haas, Kyotaro Horiguchi, Kirk Jamison, Mikalai Keida, Takayuki Tsunakawa, Andrei Yahorau Discussion: https://postgr.es/m/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04
2019-04-06 08:23:37 +02:00
else if (!setTCPUserTimeout(conn))
err = 1;
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
if (err)
{
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->try_next_addr = true;
goto keep_going;
Add TCP keepalive support to libpq. This adds four additional connection parameters to libpq: keepalives, keepalives_idle, keepalives_count, and keepalives_interval. keepalives default to on, per discussion, but can be turned off by specifying keepalives=0. The remaining parameters, where supported, can be used to adjust how often keepalives are sent and how many can be lost before the connection is broken. The immediate motivation for this patch is to make sure that walreceiver will eventually notice if the master reboots without closing the connection cleanly, but it should be helpful in other cases as well. Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
}
}
Avoid extra system calls to block SIGPIPE if the platform provides either sockopt(SO_NOSIGPIPE) or the MSG_NOSIGNAL flag to send(). We assume these features are available if (1) the symbol is defined at compile time and (2) the kernel doesn't reject the call at runtime. It might turn out that there are some platforms where (1) and (2) are true and yet the signal isn't really blocked, in which case applications would die on server crash. If that sort of thing gets reported, then we'll have to add additional defenses of some kind. Jeremy Kerr
2009-07-24 19:58:31 +02:00
/*----------
* We have three methods of blocking SIGPIPE during
* send() calls to this socket:
*
* - setsockopt(sock, SO_NOSIGPIPE)
* - send(sock, ..., MSG_NOSIGNAL)
* - setting the signal mask to SIG_IGN during send()
*
* The third method requires three syscalls per send,
* so we prefer either of the first two, but they are
* less portable. The state is tracked in the following
* members of PGconn:
*
* conn->sigpipe_so - we have set up SO_NOSIGPIPE
* conn->sigpipe_flag - we're specifying MSG_NOSIGNAL
*
* If we can use SO_NOSIGPIPE, then set sigpipe_so here
* and we're done. Otherwise, set sigpipe_flag so that
* we will try MSG_NOSIGNAL on sends. If we get an error
* with MSG_NOSIGNAL, we'll clear that flag and revert to
* signal masking.
*----------
*/
conn->sigpipe_so = false;
#ifdef MSG_NOSIGNAL
conn->sigpipe_flag = true;
#else
conn->sigpipe_flag = false;
#endif /* MSG_NOSIGNAL */
#ifdef SO_NOSIGPIPE
optval = 1;
if (setsockopt(conn->sock, SOL_SOCKET, SO_NOSIGPIPE,
(char *) &optval, sizeof(optval)) == 0)
{
conn->sigpipe_so = true;
conn->sigpipe_flag = false;
}
#endif /* SO_NOSIGPIPE */
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/*
* Start/make connection. This should not block, since we
* are in nonblock mode. If it does, well, too bad.
*/
if (connect(conn->sock, addr_cur->ai_addr,
addr_cur->ai_addrlen) < 0)
{
if (SOCK_ERRNO == EINPROGRESS ||
Expect EWOULDBLOCK from a non-blocking connect() call only on Windows. On Unix-ish platforms, EWOULDBLOCK may be the same as EAGAIN, which is *not* a success return, at least not on Linux. We need to treat it as a failure to avoid giving a misleading error message. Per the Single Unix Spec, only EINPROGRESS and EINTR returns indicate that the connection attempt is in progress. On Windows, on the other hand, EWOULDBLOCK (WSAEWOULDBLOCK) is the expected case. We must accept EINPROGRESS as well because Cygwin will return that, and it doesn't seem worth distinguishing Cygwin from native Windows here. It's not very clear whether EINTR can occur on Windows, but let's leave that part of the logic alone in the absence of concrete trouble reports. Also, remove the test for errno == 0, effectively reverting commit da9501bddb42222dc33c031b1db6ce2133bcee7b, which AFAICS was just a thinko; or at best it might have been a workaround for a platform-specific bug, which we can hope is gone now thirteen years later. In any case, since libpq makes no effort to reset errno to zero before calling connect(), it seems unlikely that that test has ever reliably done anything useful. Andres Freund and Tom Lane
2013-06-27 18:36:44 +02:00
#ifdef WIN32
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
SOCK_ERRNO == EWOULDBLOCK ||
Expect EWOULDBLOCK from a non-blocking connect() call only on Windows. On Unix-ish platforms, EWOULDBLOCK may be the same as EAGAIN, which is *not* a success return, at least not on Linux. We need to treat it as a failure to avoid giving a misleading error message. Per the Single Unix Spec, only EINPROGRESS and EINTR returns indicate that the connection attempt is in progress. On Windows, on the other hand, EWOULDBLOCK (WSAEWOULDBLOCK) is the expected case. We must accept EINPROGRESS as well because Cygwin will return that, and it doesn't seem worth distinguishing Cygwin from native Windows here. It's not very clear whether EINTR can occur on Windows, but let's leave that part of the logic alone in the absence of concrete trouble reports. Also, remove the test for errno == 0, effectively reverting commit da9501bddb42222dc33c031b1db6ce2133bcee7b, which AFAICS was just a thinko; or at best it might have been a workaround for a platform-specific bug, which we can hope is gone now thirteen years later. In any case, since libpq makes no effort to reset errno to zero before calling connect(), it seems unlikely that that test has ever reliably done anything useful. Andres Freund and Tom Lane
2013-06-27 18:36:44 +02:00
#endif
SOCK_ERRNO == EINTR)
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
{
/*
* This is fine - we're in non-blocking mode, and
* the connection is in progress. Tell caller to
* wait for write-ready on socket.
*/
conn->status = CONNECTION_STARTED;
return PGRES_POLLING_WRITING;
}
/* otherwise, trouble */
}
else
{
/*
* Hm, we're connected already --- seems the "nonblock
* connection" wasn't. Advance the state machine and
* go do the next stuff.
*/
conn->status = CONNECTION_STARTED;
goto keep_going;
}
pgindent run.
2003-08-04 02:43:34 +02:00
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/*
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
* This connection failed. Add the error report to
* conn->errorMessage, then try the next address if any.
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
*/
connectFailureMessage(conn, SOCK_ERRNO);
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->try_next_addr = true;
goto keep_going;
}
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
case CONNECTION_STARTED:
{
Remove check for accept() argument types This check was used to accommodate a staggering variety in particular in the type of the third argument of accept(). This is no longer of concern on currently supported systems. We can just use socklen_t in the code and put in a simple check that substitutes int for socklen_t if it's missing, to cover the few stragglers. Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/3538f4c4-1886-64f2-dcff-aaad8267fb82@enterprisedb.com
2021-11-09 15:20:47 +01:00
socklen_t optlen = sizeof(optval);
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/*
* Write ready, since we've made it here, so the connection
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
* has been made ... or has failed.
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
*/
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
/*
* Now check (using getsockopt) that there is not an error
* state waiting for us on the socket.
*/
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR,
Big warnings cleanup for Solaris/GCC. Down to about 40 now, but we'll get there one day. Use `cat' to create aclocal.m4, not `aclocal'. Some people don't have automake installed. Only run the autoconf rule in the top-level GNUmakefile if the invoker specified `make configure', don't run it automatically because of CVS timestamp skew.
2000-06-14 20:18:01 +02:00
(char *) &optval, &optlen) == -1)
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
{
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
NLS for libpq. Clean up the message formats and change the documentation accordingly.
2001-07-15 15:45:04 +02:00
libpq_gettext("could not get socket error status: %s\n"),
Make libpq thread-safe with configure --with-threads option. Lee Kindness
2003-06-14 19:49:54 +02:00
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
goto error_return;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
else if (optval != 0)
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
{
/*
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* When using a nonblocking connect, we will typically see
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
* connect failures at this point, so provide a friendly
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* error message.
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
*/
NLS for libpq. Clean up the message formats and change the documentation accordingly.
2001-07-15 15:45:04 +02:00
connectFailureMessage(conn, optval);
pgindent run.
2003-08-04 02:43:34 +02:00
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/*
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
* Try the next address if any, just as in the case where
* connect() returned failure immediately.
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
*/
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->try_next_addr = true;
goto keep_going;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/* Fill in the client address */
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
conn->laddr.salen = sizeof(conn->laddr.addr);
if (getsockname(conn->sock,
(struct sockaddr *) &conn->laddr.addr,
&conn->laddr.salen) < 0)
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
{
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
libpq_gettext("could not get client address from socket: %s\n"),
Make libpq thread-safe with configure --with-threads option. Lee Kindness
2003-06-14 19:49:54 +02:00
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
goto error_return;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
}
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/*
* Make sure we can write before advancing to next step.
*/
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
conn->status = CONNECTION_MADE;
return PGRES_POLLING_WRITING;
}
case CONNECTION_MADE:
{
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
char *startpacket;
int packetlen;
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
Replace use of credential control messages with getsockopt(LOCAL_PEERCRED). It turns out the reason we hadn't found out about the portability issues with our credential-control-message code is that almost no modern platforms use that code at all; the ones that used to need it now offer getpeereid(), which we choose first. The last holdout was NetBSD, and they added getpeereid() as of 5.0. So far as I can tell, the only live platform on which that code was being exercised was Debian/kFreeBSD, ie, FreeBSD kernel with Linux userland --- since glibc doesn't provide getpeereid(), we fell back to the control message code. However, the FreeBSD kernel provides a LOCAL_PEERCRED socket parameter that's functionally equivalent to Linux's SO_PEERCRED. That is both much simpler to use than control messages, and superior because it doesn't require receiving a message from the other end at just the right time. Therefore, add code to use LOCAL_PEERCRED when necessary, and rip out all the credential-control-message code in the backend. (libpq still has such code so that it can still talk to pre-9.1 servers ... but eventually we can get rid of it there too.) Clean up related autoconf probes, too. This means that libpq's requirepeer parameter now works on exactly the same platforms where the backend supports peer authentication, so adjust the documentation accordingly.
2011-05-31 22:10:46 +02:00
/*
* Implement requirepeer check, if requested and it's a
* Unix-domain socket.
*/
if (conn->requirepeer && conn->requirepeer[0] &&
Remove IS_AF_UNIX macro The AF_UNIX macro was being used unprotected by HAVE_UNIX_SOCKETS, apparently since 2008. So the redirection through IS_AF_UNIX() is apparently no longer necessary. (More generally, all supported platforms are now HAVE_UNIX_SOCKETS, but even if there were a new platform in the future, it seems plausible that it would define the AF_UNIX symbol even without kernel support.) So remove the IS_AF_UNIX() macro and make the code a bit more consistent. Discussion: https://www.postgresql.org/message-id/flat/f2d26815-9832-e333-d52d-72fbc0ade896%40enterprisedb.com
2022-02-15 10:03:52 +01:00
conn->raddr.addr.ss_family == AF_UNIX)
Add server authentication over Unix-domain sockets This adds a libpq connection parameter requirepeer that specifies the user name that the server process is expected to run under. reviewed by KaiGai Kohei
2010-07-18 13:37:26 +02:00
{
Sort out getpeereid() and peer auth handling on Windows The getpeereid() uses have so far been protected by HAVE_UNIX_SOCKETS, so they didn't ever care about Windows support. But in anticipation of Unix-domain socket support on Windows, that needs to be handled differently. Windows doesn't support getpeereid() at this time, so we use the existing not-supported code path. We let configure do its usual thing of picking up the replacement from libpgport, instead of the custom overrides that it was doing before. But then Windows doesn't have struct passwd, so this patch sprinkles some additional #ifdef WIN32 around to make it work. This is similar to existing code that deals with this issue. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/5974caea-1267-7708-40f2-6009a9d653b0@2ndquadrant.com
2019-10-30 12:58:32 +01:00
#ifndef WIN32
Clean up messy API for src/port/thread.c. The point of this patch is to reduce inclusion spam by not needing to #include <netdb.h> or <pwd.h> in port.h (which is read by every compile in our tree). To do that, we must remove port.h's declarations of pqGetpwuid and pqGethostbyname. pqGethostbyname is only used, and is only ever likely to be used, in src/port/getaddrinfo.c --- which isn't even built on most platforms, making pqGethostbyname dead code for most people. Hence, deal with that by just moving it into getaddrinfo.c. To clean up pqGetpwuid, invent a couple of simple wrapper functions with less-messy APIs. This allows removing some duplicate error-handling code, too. In passing, remove thread.c from the MSVC build, since it contains nothing we use on Windows. Noted while working on 376ce3e40. Discussion: https://postgr.es/m/1634252654444.90107@mit.edu
2022-01-11 19:46:12 +01:00
char *remote_username;
Sort out getpeereid() and peer auth handling on Windows The getpeereid() uses have so far been protected by HAVE_UNIX_SOCKETS, so they didn't ever care about Windows support. But in anticipation of Unix-domain socket support on Windows, that needs to be handled differently. Windows doesn't support getpeereid() at this time, so we use the existing not-supported code path. We let configure do its usual thing of picking up the replacement from libpgport, instead of the custom overrides that it was doing before. But then Windows doesn't have struct passwd, so this patch sprinkles some additional #ifdef WIN32 around to make it work. This is similar to existing code that deals with this issue. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/5974caea-1267-7708-40f2-6009a9d653b0@2ndquadrant.com
2019-10-30 12:58:32 +01:00
#endif
Add server authentication over Unix-domain sockets This adds a libpq connection parameter requirepeer that specifies the user name that the server process is expected to run under. reviewed by KaiGai Kohei
2010-07-18 13:37:26 +02:00
uid_t uid;
gid_t gid;
errno = 0;
Fix thinko in recent patch: 'sock' should be 'conn->sock'.
2010-07-18 18:42:20 +02:00
if (getpeereid(conn->sock, &uid, &gid) != 0)
Add server authentication over Unix-domain sockets This adds a libpq connection parameter requirepeer that specifies the user name that the server process is expected to run under. reviewed by KaiGai Kohei
2010-07-18 13:37:26 +02:00
{
Implement getpeereid() as a src/port compatibility function. This unifies a bunch of ugly #ifdef's in one place. Per discussion, we only need this where HAVE_UNIX_SOCKETS, so no need to cover Windows. Marko Kreen, some adjustment by Tom Lane
2011-06-02 19:05:01 +02:00
/*
* Provide special error message if getpeereid is a
* stub
*/
if (errno == ENOSYS)
Replace appendPQExpBuffer(..., <constant>) with appendPQExpBufferStr Arguably makes the code a bit more readable, and might give a small performance gain. David Rowley
2013-11-18 17:29:01 +01:00
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("requirepeer parameter is not supported on this platform\n"));
Implement getpeereid() as a src/port compatibility function. This unifies a bunch of ugly #ifdef's in one place. Per discussion, we only need this where HAVE_UNIX_SOCKETS, so no need to cover Windows. Marko Kreen, some adjustment by Tom Lane
2011-06-02 19:05:01 +02:00
else
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("could not get peer credentials: %s\n"),
Incorporate strerror_r() into src/port/snprintf.c, too. This provides the features that used to exist in useful_strerror() for users of strerror_r(), too. Also, standardize on the GNU convention that strerror_r returns a char pointer that may not be NULL. I notice that libpq's win32.c contains a variant version of strerror_r that probably ought to be folded into strerror.c. But lacking a Windows environment, I should leave that to somebody else. Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
2018-09-26 18:35:57 +02:00
strerror_r(errno, sebuf, sizeof(sebuf)));
Add server authentication over Unix-domain sockets This adds a libpq connection parameter requirepeer that specifies the user name that the server process is expected to run under. reviewed by KaiGai Kohei
2010-07-18 13:37:26 +02:00
goto error_return;
}
Sort out getpeereid() and peer auth handling on Windows The getpeereid() uses have so far been protected by HAVE_UNIX_SOCKETS, so they didn't ever care about Windows support. But in anticipation of Unix-domain socket support on Windows, that needs to be handled differently. Windows doesn't support getpeereid() at this time, so we use the existing not-supported code path. We let configure do its usual thing of picking up the replacement from libpgport, instead of the custom overrides that it was doing before. But then Windows doesn't have struct passwd, so this patch sprinkles some additional #ifdef WIN32 around to make it work. This is similar to existing code that deals with this issue. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/5974caea-1267-7708-40f2-6009a9d653b0@2ndquadrant.com
2019-10-30 12:58:32 +01:00
#ifndef WIN32
Clean up messy API for src/port/thread.c. The point of this patch is to reduce inclusion spam by not needing to #include <netdb.h> or <pwd.h> in port.h (which is read by every compile in our tree). To do that, we must remove port.h's declarations of pqGetpwuid and pqGethostbyname. pqGethostbyname is only used, and is only ever likely to be used, in src/port/getaddrinfo.c --- which isn't even built on most platforms, making pqGethostbyname dead code for most people. Hence, deal with that by just moving it into getaddrinfo.c. To clean up pqGetpwuid, invent a couple of simple wrapper functions with less-messy APIs. This allows removing some duplicate error-handling code, too. In passing, remove thread.c from the MSVC build, since it contains nothing we use on Windows. Noted while working on 376ce3e40. Discussion: https://postgr.es/m/1634252654444.90107@mit.edu
2022-01-11 19:46:12 +01:00
remote_username = pg_fe_getusername(uid,
&conn->errorMessage);
if (remote_username == NULL)
goto error_return; /* message already logged */
Add server authentication over Unix-domain sockets This adds a libpq connection parameter requirepeer that specifies the user name that the server process is expected to run under. reviewed by KaiGai Kohei
2010-07-18 13:37:26 +02:00
Clean up messy API for src/port/thread.c. The point of this patch is to reduce inclusion spam by not needing to #include <netdb.h> or <pwd.h> in port.h (which is read by every compile in our tree). To do that, we must remove port.h's declarations of pqGetpwuid and pqGethostbyname. pqGethostbyname is only used, and is only ever likely to be used, in src/port/getaddrinfo.c --- which isn't even built on most platforms, making pqGethostbyname dead code for most people. Hence, deal with that by just moving it into getaddrinfo.c. To clean up pqGetpwuid, invent a couple of simple wrapper functions with less-messy APIs. This allows removing some duplicate error-handling code, too. In passing, remove thread.c from the MSVC build, since it contains nothing we use on Windows. Noted while working on 376ce3e40. Discussion: https://postgr.es/m/1634252654444.90107@mit.edu
2022-01-11 19:46:12 +01:00
if (strcmp(remote_username, conn->requirepeer) != 0)
Add server authentication over Unix-domain sockets This adds a libpq connection parameter requirepeer that specifies the user name that the server process is expected to run under. reviewed by KaiGai Kohei
2010-07-18 13:37:26 +02:00
{
appendPQExpBuffer(&conn->errorMessage,
Fix up poor handling of unsupported-platform case in requirepeer patch.
2010-07-18 19:08:11 +02:00
libpq_gettext("requirepeer specifies \"%s\", but actual peer user name is \"%s\"\n"),
Clean up messy API for src/port/thread.c. The point of this patch is to reduce inclusion spam by not needing to #include <netdb.h> or <pwd.h> in port.h (which is read by every compile in our tree). To do that, we must remove port.h's declarations of pqGetpwuid and pqGethostbyname. pqGethostbyname is only used, and is only ever likely to be used, in src/port/getaddrinfo.c --- which isn't even built on most platforms, making pqGethostbyname dead code for most people. Hence, deal with that by just moving it into getaddrinfo.c. To clean up pqGetpwuid, invent a couple of simple wrapper functions with less-messy APIs. This allows removing some duplicate error-handling code, too. In passing, remove thread.c from the MSVC build, since it contains nothing we use on Windows. Noted while working on 376ce3e40. Discussion: https://postgr.es/m/1634252654444.90107@mit.edu
2022-01-11 19:46:12 +01:00
conn->requirepeer, remote_username);
free(remote_username);
Add server authentication over Unix-domain sockets This adds a libpq connection parameter requirepeer that specifies the user name that the server process is expected to run under. reviewed by KaiGai Kohei
2010-07-18 13:37:26 +02:00
goto error_return;
}
Clean up messy API for src/port/thread.c. The point of this patch is to reduce inclusion spam by not needing to #include <netdb.h> or <pwd.h> in port.h (which is read by every compile in our tree). To do that, we must remove port.h's declarations of pqGetpwuid and pqGethostbyname. pqGethostbyname is only used, and is only ever likely to be used, in src/port/getaddrinfo.c --- which isn't even built on most platforms, making pqGethostbyname dead code for most people. Hence, deal with that by just moving it into getaddrinfo.c. To clean up pqGetpwuid, invent a couple of simple wrapper functions with less-messy APIs. This allows removing some duplicate error-handling code, too. In passing, remove thread.c from the MSVC build, since it contains nothing we use on Windows. Noted while working on 376ce3e40. Discussion: https://postgr.es/m/1634252654444.90107@mit.edu
2022-01-11 19:46:12 +01:00
free(remote_username);
Sort out getpeereid() and peer auth handling on Windows The getpeereid() uses have so far been protected by HAVE_UNIX_SOCKETS, so they didn't ever care about Windows support. But in anticipation of Unix-domain socket support on Windows, that needs to be handled differently. Windows doesn't support getpeereid() at this time, so we use the existing not-supported code path. We let configure do its usual thing of picking up the replacement from libpgport, instead of the custom overrides that it was doing before. But then Windows doesn't have struct passwd, so this patch sprinkles some additional #ifdef WIN32 around to make it work. This is similar to existing code that deals with this issue. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/5974caea-1267-7708-40f2-6009a9d653b0@2ndquadrant.com
2019-10-30 12:58:32 +01:00
#else /* WIN32 */
/* should have failed with ENOSYS above */
Assert(false);
#endif /* WIN32 */
Add server authentication over Unix-domain sockets This adds a libpq connection parameter requirepeer that specifies the user name that the server process is expected to run under. reviewed by KaiGai Kohei
2010-07-18 13:37:26 +02:00
}
Remove IS_AF_UNIX macro The AF_UNIX macro was being used unprotected by HAVE_UNIX_SOCKETS, apparently since 2008. So the redirection through IS_AF_UNIX() is apparently no longer necessary. (More generally, all supported platforms are now HAVE_UNIX_SOCKETS, but even if there were a new platform in the future, it seems plausible that it would define the AF_UNIX symbol even without kernel support.) So remove the IS_AF_UNIX() macro and make the code a bit more consistent. Discussion: https://www.postgresql.org/message-id/flat/f2d26815-9832-e333-d52d-72fbc0ade896%40enterprisedb.com
2022-02-15 10:03:52 +01:00
if (conn->raddr.addr.ss_family == AF_UNIX)
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
{
/* Don't request SSL or GSSAPI over Unix sockets */
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
#ifdef USE_SSL
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
conn->allow_ssl_try = false;
#endif
#ifdef ENABLE_GSS
conn->try_gss = false;
#endif
}
#ifdef ENABLE_GSS
pgindent run.
2003-08-04 02:43:34 +02:00
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/*
Improve GSSAPI Encryption startup comment in libpq The original comment was a bit confusing, pointed out by Alvaro Herrera. Thread: https://postgr.es/m/20191224151520.GA16435%40alvherre.pgsql
2020-01-08 16:57:09 +01:00
* If GSSAPI encryption is enabled, then call
* pg_GSS_have_cred_cache() which will return true if we can
* acquire credentials (and give us a handle to use in
* conn->gcred), and then send a packet to the server asking
* for GSSAPI Encryption (and skip past SSL negotiation and
* regular startup below).
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
*/
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
if (conn->try_gss && !conn->gctx)
libpq: ccache -> credential cache The term "ccache" is overloaded. Let's be more clear, in case someone other than a Kerberos wizard has to read this code.
2019-09-06 09:15:35 +02:00
conn->try_gss = pg_GSS_have_cred_cache(&conn->gcred);
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
if (conn->try_gss && !conn->gctx)
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
{
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
ProtocolVersion pv = pg_hton32(NEGOTIATE_GSS_CODE);
if (pqPacketSend(conn, 0, &pv, sizeof(pv)) != STATUS_OK)
{
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("could not send GSSAPI negotiation packet: %s\n"),
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
goto error_return;
}
/* Ok, wait for response */
conn->status = CONNECTION_GSS_STARTUP;
return PGRES_POLLING_READING;
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
}
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
else if (!conn->gctx && conn->gssencmode[0] == 'r')
{
Use appendStringInfoString and appendPQExpBufferStr where possible This changes various places where appendPQExpBuffer was used in places where it was possible to use appendPQExpBufferStr, and likewise for appendStringInfo and appendStringInfoString. This is really just a stylistic improvement, but there are also small performance gains to be had from doing this. Discussion: http://postgr.es/m/CAKJS1f9P=M-3ULmPvr8iCno8yvfDViHibJjpriHU8+SXUgeZ=w@mail.gmail.com
2019-07-04 03:01:13 +02:00
appendPQExpBufferStr(&conn->errorMessage,
Message style fixes
2019-09-06 16:12:28 +02:00
libpq_gettext("GSSAPI encryption required but was impossible (possibly no credential cache, no server support, or using a local socket)\n"));
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
goto error_return;
}
#endif
#ifdef USE_SSL
Set libcrypto callbacks for all connection threads in libpq Based on an analysis of the OpenSSL code with Jacob, moving to EVP for the cryptohash computations makes necessary the setup of the libcrypto callbacks that were getting set only for SSL connections, but not for connections without SSL. Not setting the callbacks makes the use of threads potentially unsafe for connections calling cryptohashes during authentication, like MD5 or SCRAM, if a failure happens during a cryptohash computation. The logic setting the libssl and libcrypto states is then split into two parts, both using the same locking, with libcrypto being set up for SSL and non-SSL connections, while SSL connections set any libssl state afterwards as needed. Prior to this commit, only SSL connections would have set libcrypto callbacks that are necessary to ensure a proper thread locking when using multiple concurrent threads in libpq (ENABLE_THREAD_SAFETY). Note that this is only required for OpenSSL 1.0.2 and 1.0.1 (oldest version supported on HEAD), as 1.1.0 has its own internal locking and it has dropped support for CRYPTO_set_locking_callback(). Tests with up to 300 threads with OpenSSL 1.0.1 and 1.0.2, mixing SSL and non-SSL connection threads did not show any performance impact after some micro-benchmarking. pgbench can be used here with -C and a mostly-empty script (with one \set meta-command for example) to stress authentication requests, and we have mixed that with some custom programs for testing. Reported-by: Jacob Champion Author: Michael Paquier Reviewed-by: Jacob Champion Discussion: https://postgr.es/m/fd3ba610085f1ff54623478cf2f7adf5af193cbb.camel@vmware.com
2021-03-11 09:14:25 +01:00
/*
* Enable the libcrypto callbacks before checking if SSL needs
* to be done. This is done before sending the startup packet
* as depending on the type of authentication done, like MD5
* or SCRAM that use cryptohashes, the callbacks would be
* required even without a SSL connection
*/
if (pqsecure_initialize(conn, false, true) < 0)
goto error_return;
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
/*
Fix bugs in libpq's GSSAPI encryption support. The critical issue fixed here is that if a GSSAPI-encrypted connection is successfully made, pqsecure_open_gss() cleared conn->allow_ssl_try, as an admittedly-hacky way of preventing us from then trying to tunnel SSL encryption over the already-encrypted connection. The problem with that is that if we abandon the GSSAPI connection because of a failure during authentication, we would not attempt SSL encryption in the next try with the same server. This can lead to unexpected connection failure, or silently getting a non-encrypted connection where an encrypted one is expected. Fortunately, we'd only manage to make a GSSAPI-encrypted connection if both client and server hold valid tickets in the same Kerberos infrastructure, which is a relatively uncommon environment. Nonetheless this is a very nasty bug with potential security consequences. To fix, don't reset the flag, instead adding a check for conn->gssenc being already true when deciding whether to try to initiate SSL. While here, fix some lesser issues in libpq's GSSAPI code: * Use the need_new_connection stanza when dropping an attempted GSSAPI connection, instead of partially duplicating that code. The consequences of this are pretty minor: AFAICS it could only lead to auth_req_received or password_needed remaining set when they shouldn't, which is not too harmful. * Fix pg_GSS_error() to not repeat the "mprefix" it's given multiple times, and to notice any failure return from gss_display_status(). * Avoid gratuitous dependency on NI_MAXHOST in pg_GSS_load_servicename(). Per report from Mikael Gustavsson. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se
2020-12-28 21:43:44 +01:00
* If SSL is enabled and we haven't already got encryption of
* some sort running, request SSL instead of sending the
* startup message.
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
*/
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
if (conn->allow_ssl_try && !conn->wait_ssl_try &&
Fix bugs in libpq's GSSAPI encryption support. The critical issue fixed here is that if a GSSAPI-encrypted connection is successfully made, pqsecure_open_gss() cleared conn->allow_ssl_try, as an admittedly-hacky way of preventing us from then trying to tunnel SSL encryption over the already-encrypted connection. The problem with that is that if we abandon the GSSAPI connection because of a failure during authentication, we would not attempt SSL encryption in the next try with the same server. This can lead to unexpected connection failure, or silently getting a non-encrypted connection where an encrypted one is expected. Fortunately, we'd only manage to make a GSSAPI-encrypted connection if both client and server hold valid tickets in the same Kerberos infrastructure, which is a relatively uncommon environment. Nonetheless this is a very nasty bug with potential security consequences. To fix, don't reset the flag, instead adding a check for conn->gssenc being already true when deciding whether to try to initiate SSL. While here, fix some lesser issues in libpq's GSSAPI code: * Use the need_new_connection stanza when dropping an attempted GSSAPI connection, instead of partially duplicating that code. The consequences of this are pretty minor: AFAICS it could only lead to auth_req_received or password_needed remaining set when they shouldn't, which is not too harmful. * Fix pg_GSS_error() to not repeat the "mprefix" it's given multiple times, and to notice any failure return from gss_display_status(). * Avoid gratuitous dependency on NI_MAXHOST in pg_GSS_load_servicename(). Per report from Mikael Gustavsson. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se
2020-12-28 21:43:44 +01:00
!conn->ssl_in_use
#ifdef ENABLE_GSS
&& !conn->gssenc
#endif
)
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
{
ProtocolVersion pv;
/*
* Send the SSL request packet.
*
* Theoretically, this could block, but it really
* shouldn't since we only got here if the socket is
* write-ready.
*/
Replace most usages of ntoh[ls] and hton[sl] with pg_bswap.h. All postgres internal usages are replaced, it's just libpq example usages that haven't been converted. External users of libpq can't generally rely on including postgres internal headers. Note that this includes replacing open-coded byte swapping of 64bit integers (using two 32 bit swaps) with a single 64bit swap. Where it looked applicable, I have removed netinet/in.h and arpa/inet.h usage, which previously provided the relevant functionality. It's perfectly possible that I missed other reasons for including those, the buildfarm will tell. Author: Andres Freund Discussion: https://postgr.es/m/20170927172019.gheidqy6xvlxb325@alap3.anarazel.de
2017-10-02 00:36:14 +02:00
pv = pg_hton32(NEGOTIATE_SSL_CODE);
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
if (pqPacketSend(conn, 0, &pv, sizeof(pv)) != STATUS_OK)
{
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
libpq_gettext("could not send SSL negotiation packet: %s\n"),
Make libpq thread-safe with configure --with-threads option. Lee Kindness
2003-06-14 19:49:54 +02:00
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
goto error_return;
}
/* Ok, wait for response */
conn->status = CONNECTION_SSL_STARTUP;
return PGRES_POLLING_READING;
}
#endif /* USE_SSL */
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
/*
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
* Build the startup packet.
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
*/
Remove server and libpq support for old FE/BE protocol version 2. Protocol version 3 was introduced in PostgreSQL 7.4. There shouldn't be many clients or servers left out there without version 3 support. But as a courtesy, I kept just enough of the old protocol support that we can still send the "unsupported protocol version" error in v2 format, so that old clients can display the message properly. Likewise, libpq still understands v2 ErrorResponse messages when establishing a connection. The impetus to do this now is that I'm working on a patch to COPY FROM, to always prefetch some data. We cannot do that safely with the old protocol, because it requires parsing the input one byte at a time to detect the end-of-copy marker. Reviewed-by: Tom Lane, Alvaro Herrera, John Naylor Discussion: https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cca3b%40iki.fi
2021-03-04 09:45:55 +01:00
startpacket = pqBuildStartupPacket3(conn, &packetlen,
EnvironmentOptions);
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
if (!startpacket)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("out of memory\n"));
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
goto error_return;
}
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/*
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
* Send the startup packet.
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
*
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
* Theoretically, this could block, but it really shouldn't
* since we only got here if the socket is write-ready.
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
*/
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
if (pqPacketSend(conn, 0, startpacket, packetlen) != STATUS_OK)
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
{
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
NLS for libpq. Clean up the message formats and change the documentation accordingly.
2001-07-15 15:45:04 +02:00
libpq_gettext("could not send startup packet: %s\n"),
Make libpq thread-safe with configure --with-threads option. Lee Kindness
2003-06-14 19:49:54 +02:00
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
free(startpacket);
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
goto error_return;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
free(startpacket);
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
conn->status = CONNECTION_AWAITING_RESPONSE;
return PGRES_POLLING_READING;
}
/*
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
* Handle SSL negotiation: wait for postmaster messages and
* respond as necessary.
*/
case CONNECTION_SSL_STARTUP:
{
#ifdef USE_SSL
PostgresPollingStatusType pollres;
/*
* On first time through, get the postmaster's response to our
Instead of a bare recv() to read the server's response to an SSL request packet, use pqReadData(). This has the same effect since conn->ssl isn't set yet and we aren't expecting more than one byte. The advantage is that we will correctly detect loss-of-connection instead of going into an infinite loop. Per report from Hannu Krosing.
2005-01-06 21:06:58 +01:00
* SSL negotiation packet.
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
*/
Break out OpenSSL-specific code to separate files. This refactoring is in preparation for adding support for other SSL implementations, with no user-visible effects. There are now two #defines, USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which is defined when building with any SSL implementation. Currently, OpenSSL is the only implementation so the two #defines go together, but USE_SSL is supposed to be used for implementation-independent code. The libpq SSL code is changed to use a custom BIO, which does all the raw I/O, like we've been doing in the backend for a long time. That makes it possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids a couple of syscall for each send(). Probably doesn't make much performance difference in practice - the SSL encryption is expensive enough to mask the effect - but it was a natural result of this refactoring. Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by Alvaro Herrera, Andreas Karlsson, Jeff Janes.
2014-08-11 10:54:19 +02:00
if (!conn->ssl_in_use)
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
{
Instead of a bare recv() to read the server's response to an SSL request packet, use pqReadData(). This has the same effect since conn->ssl isn't set yet and we aren't expecting more than one byte. The advantage is that we will correctly detect loss-of-connection instead of going into an infinite loop. Per report from Hannu Krosing.
2005-01-06 21:06:58 +01:00
/*
* We use pqReadData here since it has the logic to
* distinguish no-data-yet from connection closure. Since
* conn->ssl isn't set, a plain recv() will occur.
*/
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
char SSLok;
Instead of a bare recv() to read the server's response to an SSL request packet, use pqReadData(). This has the same effect since conn->ssl isn't set yet and we aren't expecting more than one byte. The advantage is that we will correctly detect loss-of-connection instead of going into an infinite loop. Per report from Hannu Krosing.
2005-01-06 21:06:58 +01:00
int rdresult;
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
Instead of a bare recv() to read the server's response to an SSL request packet, use pqReadData(). This has the same effect since conn->ssl isn't set yet and we aren't expecting more than one byte. The advantage is that we will correctly detect loss-of-connection instead of going into an infinite loop. Per report from Hannu Krosing.
2005-01-06 21:06:58 +01:00
rdresult = pqReadData(conn);
if (rdresult < 0)
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
{
Instead of a bare recv() to read the server's response to an SSL request packet, use pqReadData(). This has the same effect since conn->ssl isn't set yet and we aren't expecting more than one byte. The advantage is that we will correctly detect loss-of-connection instead of going into an infinite loop. Per report from Hannu Krosing.
2005-01-06 21:06:58 +01:00
/* errorMessage is already filled in */
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
goto error_return;
}
Instead of a bare recv() to read the server's response to an SSL request packet, use pqReadData(). This has the same effect since conn->ssl isn't set yet and we aren't expecting more than one byte. The advantage is that we will correctly detect loss-of-connection instead of going into an infinite loop. Per report from Hannu Krosing.
2005-01-06 21:06:58 +01:00
if (rdresult == 0)
{
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/* caller failed to wait for data */
return PGRES_POLLING_READING;
Instead of a bare recv() to read the server's response to an SSL request packet, use pqReadData(). This has the same effect since conn->ssl isn't set yet and we aren't expecting more than one byte. The advantage is that we will correctly detect loss-of-connection instead of going into an infinite loop. Per report from Hannu Krosing.
2005-01-06 21:06:58 +01:00
}
if (pqGetc(&SSLok, conn) < 0)
{
/* should not happen really */
return PGRES_POLLING_READING;
}
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
if (SSLok == 'S')
{
Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server. These days, such a response is far more likely to signify a server-side problem, such as fork failure. Reporting "server does not support SSL" (in sslmode=require) could be quite misleading. But the results could be even worse in sslmode=prefer: if the problem was transient and the next connection attempt succeeds, we'll have silently fallen back to protocol version 2.0, possibly disabling features the user needs. Hence, it seems best to just eliminate the assumption that backing off to non-SSL/2.0 protocol is the way to recover from an "E" response, and instead treat the server error the same as we would in non-SSL cases. I tested this change against a pre-7.0 server, and found that there was a second logic bug in the "prefer" path: the test to decide whether to make a fallback connection attempt assumed that we must have opened conn->ssl, which in fact does not happen given an "E" response. After fixing that, the code does indeed connect successfully to pre-7.0, as long as you didn't set sslmode=require. (If you did, you get "Unsupported frontend protocol", which isn't completely off base given the server certainly doesn't support SSL.) Since there seems no reason to believe that pre-7.0 servers exist anymore in the wild, back-patch to all supported branches.
2011-08-27 22:36:57 +02:00
/* mark byte consumed */
conn->inStart = conn->inCursor;
Set libcrypto callbacks for all connection threads in libpq Based on an analysis of the OpenSSL code with Jacob, moving to EVP for the cryptohash computations makes necessary the setup of the libcrypto callbacks that were getting set only for SSL connections, but not for connections without SSL. Not setting the callbacks makes the use of threads potentially unsafe for connections calling cryptohashes during authentication, like MD5 or SCRAM, if a failure happens during a cryptohash computation. The logic setting the libssl and libcrypto states is then split into two parts, both using the same locking, with libcrypto being set up for SSL and non-SSL connections, while SSL connections set any libssl state afterwards as needed. Prior to this commit, only SSL connections would have set libcrypto callbacks that are necessary to ensure a proper thread locking when using multiple concurrent threads in libpq (ENABLE_THREAD_SAFETY). Note that this is only required for OpenSSL 1.0.2 and 1.0.1 (oldest version supported on HEAD), as 1.1.0 has its own internal locking and it has dropped support for CRYPTO_set_locking_callback(). Tests with up to 300 threads with OpenSSL 1.0.1 and 1.0.2, mixing SSL and non-SSL connection threads did not show any performance impact after some micro-benchmarking. pgbench can be used here with -C and a mostly-empty script (with one \set meta-command for example) to stress authentication requests, and we have mixed that with some custom programs for testing. Reported-by: Jacob Champion Author: Michael Paquier Reviewed-by: Jacob Champion Discussion: https://postgr.es/m/fd3ba610085f1ff54623478cf2f7adf5af193cbb.camel@vmware.com
2021-03-11 09:14:25 +01:00
/*
* Set up global SSL state if required. The crypto
* state has already been set if libpq took care of
* doing that, so there is no need to make that happen
* again.
*/
if (pqsecure_initialize(conn, true, false) != 0)
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
goto error_return;
}
else if (SSLok == 'N')
{
Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server. These days, such a response is far more likely to signify a server-side problem, such as fork failure. Reporting "server does not support SSL" (in sslmode=require) could be quite misleading. But the results could be even worse in sslmode=prefer: if the problem was transient and the next connection attempt succeeds, we'll have silently fallen back to protocol version 2.0, possibly disabling features the user needs. Hence, it seems best to just eliminate the assumption that backing off to non-SSL/2.0 protocol is the way to recover from an "E" response, and instead treat the server error the same as we would in non-SSL cases. I tested this change against a pre-7.0 server, and found that there was a second logic bug in the "prefer" path: the test to decide whether to make a fallback connection attempt assumed that we must have opened conn->ssl, which in fact does not happen given an "E" response. After fixing that, the code does indeed connect successfully to pre-7.0, as long as you didn't set sslmode=require. (If you did, you get "Unsupported frontend protocol", which isn't completely off base given the server certainly doesn't support SSL.) Since there seems no reason to believe that pre-7.0 servers exist anymore in the wild, back-patch to all supported branches.
2011-08-27 22:36:57 +02:00
/* mark byte consumed */
conn->inStart = conn->inCursor;
/* OK to do without SSL? */
Remove sslverify parameter again, replacing it with two new sslmode values: "verify-ca" and "verify-full". Since "prefer" remains the default, this will make certificate validation off by default, which should lead to less upgrade issues.
2009-04-24 11:43:10 +02:00
if (conn->sslmode[0] == 'r' || /* "require" */
conn->sslmode[0] == 'v') /* "verify-ca" or
* "verify-full" */
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
{
/* Require SSL, but server does not want it */
Replace appendPQExpBuffer(..., <constant>) with appendPQExpBufferStr Arguably makes the code a bit more readable, and might give a small performance gain. David Rowley
2013-11-18 17:29:01 +01:00
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("server does not support SSL, but SSL was required\n"));
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
goto error_return;
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
}
/* Otherwise, proceed with normal startup */
conn->allow_ssl_try = false;
Fix bugs in libpq's GSSAPI encryption support. The critical issue fixed here is that if a GSSAPI-encrypted connection is successfully made, pqsecure_open_gss() cleared conn->allow_ssl_try, as an admittedly-hacky way of preventing us from then trying to tunnel SSL encryption over the already-encrypted connection. The problem with that is that if we abandon the GSSAPI connection because of a failure during authentication, we would not attempt SSL encryption in the next try with the same server. This can lead to unexpected connection failure, or silently getting a non-encrypted connection where an encrypted one is expected. Fortunately, we'd only manage to make a GSSAPI-encrypted connection if both client and server hold valid tickets in the same Kerberos infrastructure, which is a relatively uncommon environment. Nonetheless this is a very nasty bug with potential security consequences. To fix, don't reset the flag, instead adding a check for conn->gssenc being already true when deciding whether to try to initiate SSL. While here, fix some lesser issues in libpq's GSSAPI code: * Use the need_new_connection stanza when dropping an attempted GSSAPI connection, instead of partially duplicating that code. The consequences of this are pretty minor: AFAICS it could only lead to auth_req_received or password_needed remaining set when they shouldn't, which is not too harmful. * Fix pg_GSS_error() to not repeat the "mprefix" it's given multiple times, and to notice any failure return from gss_display_status(). * Avoid gratuitous dependency on NI_MAXHOST in pg_GSS_load_servicename(). Per report from Mikael Gustavsson. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se
2020-12-28 21:43:44 +01:00
/* We can proceed using this connection */
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
conn->status = CONNECTION_MADE;
return PGRES_POLLING_WRITING;
}
else if (SSLok == 'E')
{
Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server. These days, such a response is far more likely to signify a server-side problem, such as fork failure. Reporting "server does not support SSL" (in sslmode=require) could be quite misleading. But the results could be even worse in sslmode=prefer: if the problem was transient and the next connection attempt succeeds, we'll have silently fallen back to protocol version 2.0, possibly disabling features the user needs. Hence, it seems best to just eliminate the assumption that backing off to non-SSL/2.0 protocol is the way to recover from an "E" response, and instead treat the server error the same as we would in non-SSL cases. I tested this change against a pre-7.0 server, and found that there was a second logic bug in the "prefer" path: the test to decide whether to make a fallback connection attempt assumed that we must have opened conn->ssl, which in fact does not happen given an "E" response. After fixing that, the code does indeed connect successfully to pre-7.0, as long as you didn't set sslmode=require. (If you did, you get "Unsupported frontend protocol", which isn't completely off base given the server certainly doesn't support SSL.) Since there seems no reason to believe that pre-7.0 servers exist anymore in the wild, back-patch to all supported branches.
2011-08-27 22:36:57 +02:00
/*
* Server failure of some sort, such as failure to
* fork a backend process. We need to process and
* report the error message, which might be formatted
* according to either protocol 2 or protocol 3.
* Rather than duplicate the code for that, we flip
* into AWAITING_RESPONSE state and let the code there
* deal with it. Note we have *not* consumed the "E"
* byte here.
*/
conn->status = CONNECTION_AWAITING_RESPONSE;
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
goto keep_going;
}
else
{
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
libpq_gettext("received invalid response to SSL negotiation: %c\n"),
SSLok);
goto error_return;
}
}
pgindent run.
2003-08-04 02:43:34 +02:00
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/*
* Begin or continue the SSL negotiation process.
*/
pollres = pqsecure_open_client(conn);
if (pollres == PGRES_POLLING_OK)
{
libpq: reject extraneous data after SSL or GSS encryption handshake. libpq collects up to a bufferload of data whenever it reads data from the socket. When SSL or GSS encryption is requested during startup, any additional data received with the server's yes-or-no reply remained in the buffer, and would be treated as already-decrypted data once the encryption handshake completed. Thus, a man-in-the-middle with the ability to inject data into the TCP connection could stuff some cleartext data into the start of a supposedly encryption-protected database session. This could probably be abused to inject faked responses to the client's first few queries, although other details of libpq's behavior make that harder than it sounds. A different line of attack is to exfiltrate the client's password, or other sensitive data that might be sent early in the session. That has been shown to be possible with a server vulnerable to CVE-2021-23214. To fix, throw a protocol-violation error if the internal buffer is not empty after the encryption handshake. Our thanks to Jacob Champion for reporting this problem. Security: CVE-2021-23222
2021-11-08 17:14:56 +01:00
/*
* At this point we should have no data already buffered.
* If we do, it was received before we performed the SSL
* handshake, so it wasn't encrypted and indeed may have
* been injected by a man-in-the-middle.
*/
if (conn->inCursor != conn->inEnd)
{
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("received unencrypted data after SSL response\n"));
goto error_return;
}
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/* SSL handshake done, ready to send startup packet */
conn->status = CONNECTION_MADE;
return PGRES_POLLING_WRITING;
}
If SSL negotiation fails and SSLMODE is 'prefer', then retry without SSL. Negotiation failure is only likely to happen if one side or the other is misconfigured, eg. bad client certificate. I'm not 100% convinced that a retry is really the best thing, hence not back-patching this fix for now. Per gripe from Sergio Cinos.
2006-11-21 17:28:00 +01:00
if (pollres == PGRES_POLLING_FAILED)
{
/*
* Failed ... if sslmode is "prefer" then do a non-SSL
* retry
*/
if (conn->sslmode[0] == 'p' /* "prefer" */
&& conn->allow_ssl_try /* redundant? */
&& !conn->wait_ssl_try) /* redundant? */
{
/* only retry once */
conn->allow_ssl_try = false;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
need_new_connection = true;
If SSL negotiation fails and SSLMODE is 'prefer', then retry without SSL. Negotiation failure is only likely to happen if one side or the other is misconfigured, eg. bad client certificate. I'm not 100% convinced that a retry is really the best thing, hence not back-patching this fix for now. Per gripe from Sergio Cinos.
2006-11-21 17:28:00 +01:00
goto keep_going;
}
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/* Else it's a hard failure */
goto error_return;
If SSL negotiation fails and SSLMODE is 'prefer', then retry without SSL. Negotiation failure is only likely to happen if one side or the other is misconfigured, eg. bad client certificate. I'm not 100% convinced that a retry is really the best thing, hence not back-patching this fix for now. Per gripe from Sergio Cinos.
2006-11-21 17:28:00 +01:00
}
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/* Else, return POLLING_READING or POLLING_WRITING status */
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
return pollres;
#else /* !USE_SSL */
/* can't get here */
goto error_return;
#endif /* USE_SSL */
}
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
case CONNECTION_GSS_STARTUP:
{
#ifdef ENABLE_GSS
PostgresPollingStatusType pollres;
/*
* If we haven't yet, get the postmaster's response to our
* negotiation packet
*/
if (conn->try_gss && !conn->gctx)
{
char gss_ok;
int rdresult = pqReadData(conn);
if (rdresult < 0)
/* pqReadData fills in error message */
goto error_return;
else if (rdresult == 0)
/* caller failed to wait for data */
return PGRES_POLLING_READING;
if (pqGetc(&gss_ok, conn) < 0)
/* shouldn't happen... */
return PGRES_POLLING_READING;
if (gss_ok == 'E')
{
/*
* Server failure of some sort. Assume it's a
* protocol version support failure, and let's see if
* we can't recover (if it's not, we'll get a better
* error message on retry). Server gets fussy if we
* don't hang up the socket, though.
*/
conn->try_gss = false;
Fix bugs in libpq's GSSAPI encryption support. The critical issue fixed here is that if a GSSAPI-encrypted connection is successfully made, pqsecure_open_gss() cleared conn->allow_ssl_try, as an admittedly-hacky way of preventing us from then trying to tunnel SSL encryption over the already-encrypted connection. The problem with that is that if we abandon the GSSAPI connection because of a failure during authentication, we would not attempt SSL encryption in the next try with the same server. This can lead to unexpected connection failure, or silently getting a non-encrypted connection where an encrypted one is expected. Fortunately, we'd only manage to make a GSSAPI-encrypted connection if both client and server hold valid tickets in the same Kerberos infrastructure, which is a relatively uncommon environment. Nonetheless this is a very nasty bug with potential security consequences. To fix, don't reset the flag, instead adding a check for conn->gssenc being already true when deciding whether to try to initiate SSL. While here, fix some lesser issues in libpq's GSSAPI code: * Use the need_new_connection stanza when dropping an attempted GSSAPI connection, instead of partially duplicating that code. The consequences of this are pretty minor: AFAICS it could only lead to auth_req_received or password_needed remaining set when they shouldn't, which is not too harmful. * Fix pg_GSS_error() to not repeat the "mprefix" it's given multiple times, and to notice any failure return from gss_display_status(). * Avoid gratuitous dependency on NI_MAXHOST in pg_GSS_load_servicename(). Per report from Mikael Gustavsson. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se
2020-12-28 21:43:44 +01:00
need_new_connection = true;
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
goto keep_going;
}
/* mark byte consumed */
conn->inStart = conn->inCursor;
if (gss_ok == 'N')
{
/* Server doesn't want GSSAPI; fall back if we can */
if (conn->gssencmode[0] == 'r')
{
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("server doesn't support GSSAPI encryption, but it was required\n"));
goto error_return;
}
conn->try_gss = false;
Fix bugs in libpq's GSSAPI encryption support. The critical issue fixed here is that if a GSSAPI-encrypted connection is successfully made, pqsecure_open_gss() cleared conn->allow_ssl_try, as an admittedly-hacky way of preventing us from then trying to tunnel SSL encryption over the already-encrypted connection. The problem with that is that if we abandon the GSSAPI connection because of a failure during authentication, we would not attempt SSL encryption in the next try with the same server. This can lead to unexpected connection failure, or silently getting a non-encrypted connection where an encrypted one is expected. Fortunately, we'd only manage to make a GSSAPI-encrypted connection if both client and server hold valid tickets in the same Kerberos infrastructure, which is a relatively uncommon environment. Nonetheless this is a very nasty bug with potential security consequences. To fix, don't reset the flag, instead adding a check for conn->gssenc being already true when deciding whether to try to initiate SSL. While here, fix some lesser issues in libpq's GSSAPI code: * Use the need_new_connection stanza when dropping an attempted GSSAPI connection, instead of partially duplicating that code. The consequences of this are pretty minor: AFAICS it could only lead to auth_req_received or password_needed remaining set when they shouldn't, which is not too harmful. * Fix pg_GSS_error() to not repeat the "mprefix" it's given multiple times, and to notice any failure return from gss_display_status(). * Avoid gratuitous dependency on NI_MAXHOST in pg_GSS_load_servicename(). Per report from Mikael Gustavsson. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se
2020-12-28 21:43:44 +01:00
/* We can proceed using this connection */
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
conn->status = CONNECTION_MADE;
return PGRES_POLLING_WRITING;
}
else if (gss_ok != 'G')
{
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("received invalid response to GSSAPI negotiation: %c\n"),
gss_ok);
goto error_return;
}
}
/* Begin or continue GSSAPI negotiation */
pollres = pqsecure_open_gss(conn);
if (pollres == PGRES_POLLING_OK)
{
libpq: reject extraneous data after SSL or GSS encryption handshake. libpq collects up to a bufferload of data whenever it reads data from the socket. When SSL or GSS encryption is requested during startup, any additional data received with the server's yes-or-no reply remained in the buffer, and would be treated as already-decrypted data once the encryption handshake completed. Thus, a man-in-the-middle with the ability to inject data into the TCP connection could stuff some cleartext data into the start of a supposedly encryption-protected database session. This could probably be abused to inject faked responses to the client's first few queries, although other details of libpq's behavior make that harder than it sounds. A different line of attack is to exfiltrate the client's password, or other sensitive data that might be sent early in the session. That has been shown to be possible with a server vulnerable to CVE-2021-23214. To fix, throw a protocol-violation error if the internal buffer is not empty after the encryption handshake. Our thanks to Jacob Champion for reporting this problem. Security: CVE-2021-23222
2021-11-08 17:14:56 +01:00
/*
* At this point we should have no data already buffered.
* If we do, it was received before we performed the GSS
* handshake, so it wasn't encrypted and indeed may have
* been injected by a man-in-the-middle.
*/
if (conn->inCursor != conn->inEnd)
{
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("received unencrypted data after GSSAPI encryption response\n"));
goto error_return;
}
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
/* All set for startup packet */
conn->status = CONNECTION_MADE;
return PGRES_POLLING_WRITING;
}
else if (pollres == PGRES_POLLING_FAILED &&
conn->gssencmode[0] == 'p')
{
/*
* We failed, but we can retry on "prefer". Have to drop
* the current connection to do so, though.
*/
conn->try_gss = false;
Fix bugs in libpq's GSSAPI encryption support. The critical issue fixed here is that if a GSSAPI-encrypted connection is successfully made, pqsecure_open_gss() cleared conn->allow_ssl_try, as an admittedly-hacky way of preventing us from then trying to tunnel SSL encryption over the already-encrypted connection. The problem with that is that if we abandon the GSSAPI connection because of a failure during authentication, we would not attempt SSL encryption in the next try with the same server. This can lead to unexpected connection failure, or silently getting a non-encrypted connection where an encrypted one is expected. Fortunately, we'd only manage to make a GSSAPI-encrypted connection if both client and server hold valid tickets in the same Kerberos infrastructure, which is a relatively uncommon environment. Nonetheless this is a very nasty bug with potential security consequences. To fix, don't reset the flag, instead adding a check for conn->gssenc being already true when deciding whether to try to initiate SSL. While here, fix some lesser issues in libpq's GSSAPI code: * Use the need_new_connection stanza when dropping an attempted GSSAPI connection, instead of partially duplicating that code. The consequences of this are pretty minor: AFAICS it could only lead to auth_req_received or password_needed remaining set when they shouldn't, which is not too harmful. * Fix pg_GSS_error() to not repeat the "mprefix" it's given multiple times, and to notice any failure return from gss_display_status(). * Avoid gratuitous dependency on NI_MAXHOST in pg_GSS_load_servicename(). Per report from Mikael Gustavsson. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se
2020-12-28 21:43:44 +01:00
need_new_connection = true;
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
goto keep_going;
}
return pollres;
#else /* !ENABLE_GSS */
/* unreachable */
goto error_return;
#endif /* ENABLE_GSS */
}
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
/*
* Handle authentication exchange: wait for postmaster messages
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* and respond as necessary.
*/
case CONNECTION_AWAITING_RESPONSE:
{
char beresp;
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
int msgLength;
int avail;
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
AuthRequest areq;
Refactor libpq authentication request processing. Move the responsibility of reading the data from the authentication request message from PQconnectPoll() to pg_fe_sendauth(). This way, PQconnectPoll() doesn't need to know about all the different authentication request types, and we don't need the extra fields in the pg_conn struct to pass the data from PQconnectPoll() to pg_fe_sendauth() anymore. Reviewed by Michael Paquier. Discussion: https://www.postgresql.org/message-id/6490b975-5ee1-6280-ac1d-af975b19fb9a%40iki.fi
2017-04-13 18:34:14 +02:00
int res;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
/*
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
* Scan the message from current point (note that if we find
* the message is incomplete, we will return without advancing
* inStart, and resume here next time).
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
*/
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
conn->inCursor = conn->inStart;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
/* Read type byte */
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
if (pqGetc(&beresp, conn))
{
More connection timeout cleanups.
2002-08-27 17:02:50 +02:00
/* We'll come back when there is more data */
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
return PGRES_POLLING_READING;
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
/*
* Validate message type: we expect only an authentication
* request or an error here. Anything else probably means
* it's not Postgres on the other end at all.
*/
if (!(beresp == 'R' || beresp == 'E'))
{
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
libpq_gettext("expected authentication request from server, but received %c\n"),
beresp);
goto error_return;
}
Remove server and libpq support for old FE/BE protocol version 2. Protocol version 3 was introduced in PostgreSQL 7.4. There shouldn't be many clients or servers left out there without version 3 support. But as a courtesy, I kept just enough of the old protocol support that we can still send the "unsupported protocol version" error in v2 format, so that old clients can display the message properly. Likewise, libpq still understands v2 ErrorResponse messages when establishing a connection. The impetus to do this now is that I'm working on a patch to COPY FROM, to always prefetch some data. We cannot do that safely with the old protocol, because it requires parsing the input one byte at a time to detect the end-of-copy marker. Reviewed-by: Tom Lane, Alvaro Herrera, John Naylor Discussion: https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cca3b%40iki.fi
2021-03-04 09:45:55 +01:00
/* Read message length word */
if (pqGetInt(&msgLength, 4, conn))
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
{
Remove server and libpq support for old FE/BE protocol version 2. Protocol version 3 was introduced in PostgreSQL 7.4. There shouldn't be many clients or servers left out there without version 3 support. But as a courtesy, I kept just enough of the old protocol support that we can still send the "unsupported protocol version" error in v2 format, so that old clients can display the message properly. Likewise, libpq still understands v2 ErrorResponse messages when establishing a connection. The impetus to do this now is that I'm working on a patch to COPY FROM, to always prefetch some data. We cannot do that safely with the old protocol, because it requires parsing the input one byte at a time to detect the end-of-copy marker. Reviewed-by: Tom Lane, Alvaro Herrera, John Naylor Discussion: https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cca3b%40iki.fi
2021-03-04 09:45:55 +01:00
/* We'll come back when there is more data */
return PGRES_POLLING_READING;
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
}
/*
* Try to validate message length before using it.
Add support for GSSAPI authentication. Documentation still being written, will be committed later. Henry B. Hotz and Magnus Hagander
2007-07-10 15:14:22 +02:00
* Authentication requests can't be very large, although GSS
* auth requests may not be that small. Errors can be a
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
* little larger, but not huge. If we see a large apparent
* length in an error, it means we're really talking to a
Remove server and libpq support for old FE/BE protocol version 2. Protocol version 3 was introduced in PostgreSQL 7.4. There shouldn't be many clients or servers left out there without version 3 support. But as a courtesy, I kept just enough of the old protocol support that we can still send the "unsupported protocol version" error in v2 format, so that old clients can display the message properly. Likewise, libpq still understands v2 ErrorResponse messages when establishing a connection. The impetus to do this now is that I'm working on a patch to COPY FROM, to always prefetch some data. We cannot do that safely with the old protocol, because it requires parsing the input one byte at a time to detect the end-of-copy marker. Reviewed-by: Tom Lane, Alvaro Herrera, John Naylor Discussion: https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cca3b%40iki.fi
2021-03-04 09:45:55 +01:00
* pre-3.0-protocol server; cope. (Before version 14, the
* server also used the old protocol for errors that happened
* before processing the startup packet.)
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
*/
Add support for GSSAPI authentication. Documentation still being written, will be committed later. Henry B. Hotz and Magnus Hagander
2007-07-10 15:14:22 +02:00
if (beresp == 'R' && (msgLength < 8 || msgLength > 2000))
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
{
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
libpq_gettext("expected authentication request from server, but received %c\n"),
beresp);
goto error_return;
}
if (beresp == 'E' && (msgLength < 8 || msgLength > 30000))
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
{
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
/* Handle error from a pre-3.0 server */
conn->inCursor = conn->inStart + 1; /* reread data */
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
if (pqGets_append(&conn->errorMessage, conn))
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
{
The attached patch implements the password packet length sanity check (using an elog(LOG) ), as well as includes a few more comment fixes. Neil Conway
2002-08-27 18:21:51 +02:00
/* We'll come back when there is more data */
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
return PGRES_POLLING_READING;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/* OK, we read the message; mark data consumed */
conn->inStart = conn->inCursor;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
/*
Avoid extra newline in errors received in FE protocol version 2. Contrary to what the comment said, the postmaster does in fact end all its messages in a newline, since server version 7.2. Be tidy and don't add an extra newline if the error message already has one. Discussion: https://www.postgresql.org/message-id/CAFBsxsEdgMXc%2BtGfEy9Y41i%3D5pMMjKeH8t8vSAypR3ZnAoQnHg%40mail.gmail.com
2021-03-04 09:56:33 +01:00
* Before 7.2, the postmaster didn't always end its
* messages with a newline, so add one if needed to
* conform to libpq conventions.
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
*/
Avoid extra newline in errors received in FE protocol version 2. Contrary to what the comment said, the postmaster does in fact end all its messages in a newline, since server version 7.2. Be tidy and don't add an extra newline if the error message already has one. Discussion: https://www.postgresql.org/message-id/CAFBsxsEdgMXc%2BtGfEy9Y41i%3D5pMMjKeH8t8vSAypR3ZnAoQnHg%40mail.gmail.com
2021-03-04 09:56:33 +01:00
if (conn->errorMessage.len == 0 ||
conn->errorMessage.data[conn->errorMessage.len - 1] != '\n')
{
appendPQExpBufferChar(&conn->errorMessage, '\n');
}
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
goto error_return;
}
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
/*
* Can't process if message body isn't all here yet.
*/
msgLength -= 4;
avail = conn->inEnd - conn->inCursor;
if (avail < msgLength)
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
{
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
/*
* Before returning, try to enlarge the input buffer if
* needed to hold the whole message; see notes in
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
* pqParseInput3.
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
*/
Tweak libpq to avoid crashing due to incorrect buffer size calculation when we are on a 64-bit machine (ie, size_t is wider than int) and someone passes in a query string that approaches or exceeds INT_MAX bytes. Also, just for paranoia's sake, guard against similar overflows in sizing the input buffer. The backend will not in the foreseeable future be prepared to send or receive strings exceeding 1GB, so I didn't take the more invasive step of switching all the buffer index variables from int to size_t; though someday we might want to do that. I have a suspicion that this is not the only such bug in libpq, but this fix is enough to take care of the crash reported by Francisco Reyes.
2008-05-30 00:02:44 +02:00
if (pqCheckInBufferSpace(conn->inCursor + (size_t) msgLength,
conn))
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
goto error_return;
/* We'll come back when there is more data */
return PGRES_POLLING_READING;
}
/* Handle errors. */
if (beresp == 'E')
{
Remove server and libpq support for old FE/BE protocol version 2. Protocol version 3 was introduced in PostgreSQL 7.4. There shouldn't be many clients or servers left out there without version 3 support. But as a courtesy, I kept just enough of the old protocol support that we can still send the "unsupported protocol version" error in v2 format, so that old clients can display the message properly. Likewise, libpq still understands v2 ErrorResponse messages when establishing a connection. The impetus to do this now is that I'm working on a patch to COPY FROM, to always prefetch some data. We cannot do that safely with the old protocol, because it requires parsing the input one byte at a time to detect the end-of-copy marker. Reviewed-by: Tom Lane, Alvaro Herrera, John Naylor Discussion: https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cca3b%40iki.fi
2021-03-04 09:45:55 +01:00
if (pqGetErrorNotice3(conn, true))
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
{
Remove server and libpq support for old FE/BE protocol version 2. Protocol version 3 was introduced in PostgreSQL 7.4. There shouldn't be many clients or servers left out there without version 3 support. But as a courtesy, I kept just enough of the old protocol support that we can still send the "unsupported protocol version" error in v2 format, so that old clients can display the message properly. Likewise, libpq still understands v2 ErrorResponse messages when establishing a connection. The impetus to do this now is that I'm working on a patch to COPY FROM, to always prefetch some data. We cannot do that safely with the old protocol, because it requires parsing the input one byte at a time to detect the end-of-copy marker. Reviewed-by: Tom Lane, Alvaro Herrera, John Naylor Discussion: https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cca3b%40iki.fi
2021-03-04 09:45:55 +01:00
/* We'll come back when there is more data */
return PGRES_POLLING_READING;
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
}
/* OK, we read the message; mark data consumed */
conn->inStart = conn->inCursor;
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
Try next host after a "cannot connect now" failure. If a server returns ERRCODE_CANNOT_CONNECT_NOW, try the next host, if multiple host names have been provided. This allows dealing gracefully with standby servers that might not be in hot standby mode yet. In the wake of the preceding commit, it might be plausible to retry many more error cases than we do now, but I (tgl) am hesitant to move too aggressively on that --- it's not clear it'd be desirable for cases such as bad-password, for example. But this case seems safe enough. Hubert Zhang, reviewed by Takayuki Tsunakawa Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 20:12:31 +01:00
/*
* If error is "cannot connect now", try the next host if
* any (but we don't want to consider additional addresses
* for this host, nor is there much point in changing SSL
* or GSS mode). This is helpful when dealing with
* standby servers that might not be in hot-standby state.
*/
if (strcmp(conn->last_sqlstate,
ERRCODE_CANNOT_CONNECT_NOW) == 0)
{
conn->try_next_host = true;
goto keep_going;
}
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/* Check to see if we should mention pgpassfile */
pgpassfileWarning(conn);
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
#ifdef ENABLE_GSS
/*
* If gssencmode is "prefer" and we're using GSSAPI, retry
* without it.
*/
if (conn->gssenc && conn->gssencmode[0] == 'p')
{
Fix bugs in libpq's GSSAPI encryption support. The critical issue fixed here is that if a GSSAPI-encrypted connection is successfully made, pqsecure_open_gss() cleared conn->allow_ssl_try, as an admittedly-hacky way of preventing us from then trying to tunnel SSL encryption over the already-encrypted connection. The problem with that is that if we abandon the GSSAPI connection because of a failure during authentication, we would not attempt SSL encryption in the next try with the same server. This can lead to unexpected connection failure, or silently getting a non-encrypted connection where an encrypted one is expected. Fortunately, we'd only manage to make a GSSAPI-encrypted connection if both client and server hold valid tickets in the same Kerberos infrastructure, which is a relatively uncommon environment. Nonetheless this is a very nasty bug with potential security consequences. To fix, don't reset the flag, instead adding a check for conn->gssenc being already true when deciding whether to try to initiate SSL. While here, fix some lesser issues in libpq's GSSAPI code: * Use the need_new_connection stanza when dropping an attempted GSSAPI connection, instead of partially duplicating that code. The consequences of this are pretty minor: AFAICS it could only lead to auth_req_received or password_needed remaining set when they shouldn't, which is not too harmful. * Fix pg_GSS_error() to not repeat the "mprefix" it's given multiple times, and to notice any failure return from gss_display_status(). * Avoid gratuitous dependency on NI_MAXHOST in pg_GSS_load_servicename(). Per report from Mikael Gustavsson. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se
2020-12-28 21:43:44 +01:00
/* only retry once */
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
conn->try_gss = false;
Fix bugs in libpq's GSSAPI encryption support. The critical issue fixed here is that if a GSSAPI-encrypted connection is successfully made, pqsecure_open_gss() cleared conn->allow_ssl_try, as an admittedly-hacky way of preventing us from then trying to tunnel SSL encryption over the already-encrypted connection. The problem with that is that if we abandon the GSSAPI connection because of a failure during authentication, we would not attempt SSL encryption in the next try with the same server. This can lead to unexpected connection failure, or silently getting a non-encrypted connection where an encrypted one is expected. Fortunately, we'd only manage to make a GSSAPI-encrypted connection if both client and server hold valid tickets in the same Kerberos infrastructure, which is a relatively uncommon environment. Nonetheless this is a very nasty bug with potential security consequences. To fix, don't reset the flag, instead adding a check for conn->gssenc being already true when deciding whether to try to initiate SSL. While here, fix some lesser issues in libpq's GSSAPI code: * Use the need_new_connection stanza when dropping an attempted GSSAPI connection, instead of partially duplicating that code. The consequences of this are pretty minor: AFAICS it could only lead to auth_req_received or password_needed remaining set when they shouldn't, which is not too harmful. * Fix pg_GSS_error() to not repeat the "mprefix" it's given multiple times, and to notice any failure return from gss_display_status(). * Avoid gratuitous dependency on NI_MAXHOST in pg_GSS_load_servicename(). Per report from Mikael Gustavsson. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se
2020-12-28 21:43:44 +01:00
need_new_connection = true;
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
goto keep_going;
}
#endif
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
#ifdef USE_SSL
pgindent run.
2003-08-04 02:43:34 +02:00
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
/*
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
* if sslmode is "allow" and we haven't tried an SSL
* connection already, then retry with an SSL connection
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
*/
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
if (conn->sslmode[0] == 'a' /* "allow" */
Break out OpenSSL-specific code to separate files. This refactoring is in preparation for adding support for other SSL implementations, with no user-visible effects. There are now two #defines, USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which is defined when building with any SSL implementation. Currently, OpenSSL is the only implementation so the two #defines go together, but USE_SSL is supposed to be used for implementation-independent code. The libpq SSL code is changed to use a custom BIO, which does all the raw I/O, like we've been doing in the backend for a long time. That makes it possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids a couple of syscall for each send(). Probably doesn't make much performance difference in practice - the SSL encryption is expensive enough to mask the effect - but it was a natural result of this refactoring. Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by Alvaro Herrera, Andreas Karlsson, Jeff Janes.
2014-08-11 10:54:19 +02:00
&& !conn->ssl_in_use
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
&& conn->allow_ssl_try
&& conn->wait_ssl_try)
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
{
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
/* only retry once */
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
conn->wait_ssl_try = false;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
need_new_connection = true;
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
goto keep_going;
}
/*
* if sslmode is "prefer" and we're in an SSL connection,
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
* then do a non-SSL retry
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
*/
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
if (conn->sslmode[0] == 'p' /* "prefer" */
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
&& conn->ssl_in_use
&& conn->allow_ssl_try /* redundant? */
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
&& !conn->wait_ssl_try) /* redundant? */
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
{
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
/* only retry once */
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
conn->allow_ssl_try = false;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
need_new_connection = true;
At long last I put together a patch to support 4 client SSL negotiation modes (and replace the requiressl boolean). The four options were first spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email to pgsql-hackers, archived here: http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php My original less-flexible patch and the ensuing thread are archived at: http://dbforums.com/t623845.html Attached is a new patch, including documentation. To sum up, there's a new client parameter "sslmode" and environment variable "PGSSLMODE", with these options: sslmode description ------- ----------- disable Unencrypted non-SSL only allow Negotiate, prefer non-SSL prefer Negotiate, prefer SSL (default) require Require SSL The only change to the server is a new pg_hba.conf line type, "hostnossl", for specifying connections that are not allowed to use SSL (for example, to prevent servers on a local network from accidentally using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are: pg_hba.conf line types ---------------------- host applies to either SSL or regular connections hostssl applies only to SSL connections hostnossl applies only to regular connections These client and server options, the postgresql.conf ssl = false option, and finally the possibility of compiling with no SSL support at all, make quite a range of combinations to test. I threw together a test script to try many of them out. It's in a separate tarball with its config files, a patch to psql so it'll announce SSL connections even in absence of a tty, and the test output. The test is especially informative when run on the same tty the postmaster was started on, so the FATAL: errors during negotiation are interleaved with the psql client output. I saw Tom write that new submissions for 7.4 have to be in before midnight local time, and since I'm on the east coast in the US, this just makes it in before the bell. :) Jon Jensen
2003-07-26 15:50:02 +02:00
goto keep_going;
}
#endif
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
goto error_return;
}
Another round of protocol changes. Backend-to-frontend messages now all have length words. COPY OUT reimplemented per new protocol: it doesn't need \. anymore, thank goodness. COPY BINARY to/from frontend works, at least as far as the backend is concerned --- libpq's PQgetline API is not up to snuff, and will have to be replaced with something that is null-safe. libpq uses message length words for performance improvement (no cycles wasted rescanning long messages), but not yet for error recovery.
2003-04-22 02:08:07 +02:00
/* It is an authentication request. */
On further testing, PQping also needs an explicit check for AUTH_REQ. The pg_fe_sendauth code might fail if it can't handle the authentication request message type --- if so, ping should still say the server is up.
2010-11-27 08:11:45 +01:00
conn->auth_req_received = true;
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/* Get the type of request. */
if (pqGetInt((int *) &areq, 4, conn))
{
/* We'll come back when there are more data */
return PGRES_POLLING_READING;
}
Refactor libpq authentication request processing. Move the responsibility of reading the data from the authentication request message from PQconnectPoll() to pg_fe_sendauth(). This way, PQconnectPoll() doesn't need to know about all the different authentication request types, and we don't need the extra fields in the pg_conn struct to pass the data from PQconnectPoll() to pg_fe_sendauth() anymore. Reviewed by Michael Paquier. Discussion: https://www.postgresql.org/message-id/6490b975-5ee1-6280-ac1d-af975b19fb9a%40iki.fi
2017-04-13 18:34:14 +02:00
msgLength -= 4;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
/*
Refactor libpq authentication request processing. Move the responsibility of reading the data from the authentication request message from PQconnectPoll() to pg_fe_sendauth(). This way, PQconnectPoll() doesn't need to know about all the different authentication request types, and we don't need the extra fields in the pg_conn struct to pass the data from PQconnectPoll() to pg_fe_sendauth() anymore. Reviewed by Michael Paquier. Discussion: https://www.postgresql.org/message-id/6490b975-5ee1-6280-ac1d-af975b19fb9a%40iki.fi
2017-04-13 18:34:14 +02:00
* Process the rest of the authentication request message, and
* respond to it if necessary.
*
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
* Note that conn->pghost must be non-NULL if we are going to
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* avoid the Kerberos code doing a hostname look-up.
*/
Refactor libpq authentication request processing. Move the responsibility of reading the data from the authentication request message from PQconnectPoll() to pg_fe_sendauth(). This way, PQconnectPoll() doesn't need to know about all the different authentication request types, and we don't need the extra fields in the pg_conn struct to pass the data from PQconnectPoll() to pg_fe_sendauth() anymore. Reviewed by Michael Paquier. Discussion: https://www.postgresql.org/message-id/6490b975-5ee1-6280-ac1d-af975b19fb9a%40iki.fi
2017-04-13 18:34:14 +02:00
res = pg_fe_sendauth(areq, msgLength, conn);
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Refactor libpq authentication request processing. Move the responsibility of reading the data from the authentication request message from PQconnectPoll() to pg_fe_sendauth(). This way, PQconnectPoll() doesn't need to know about all the different authentication request types, and we don't need the extra fields in the pg_conn struct to pass the data from PQconnectPoll() to pg_fe_sendauth() anymore. Reviewed by Michael Paquier. Discussion: https://www.postgresql.org/message-id/6490b975-5ee1-6280-ac1d-af975b19fb9a%40iki.fi
2017-04-13 18:34:14 +02:00
/* OK, we have processed the message; mark data consumed */
conn->inStart = conn->inCursor;
if (res != STATUS_OK)
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
goto error_return;
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
/*
Clean up libpq's pollution of application namespace by renaming the exported routines of ip.c, md5.c, and fe-auth.c to begin with 'pg_'. Also get rid of the vestigial fe_setauthsvc/fe_getauthsvc routines altogether.
2005-10-17 18:24:20 +02:00
* Just make sure that any data sent by pg_fe_sendauth is
* flushed out. Although this theoretically could block, it
* really shouldn't since we don't send large auth responses.
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
*/
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
if (pqFlush(conn))
goto error_return;
if (areq == AUTH_REQ_OK)
{
/* We are done with authentication exchange */
conn->status = CONNECTION_AUTH_OK;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/*
Add a "row processor" API to libpq for better handling of large results. Traditionally libpq has collected an entire query result before passing it back to the application. That provides a simple and transactional API, but it's pretty inefficient for large result sets. This patch allows the application to process each row on-the-fly instead of accumulating the rows into the PGresult. Error recovery becomes a bit more complex, but often that tradeoff is well worth making. Kyotaro Horiguchi, reviewed by Marko Kreen and Tom Lane
2012-04-05 00:27:56 +02:00
* Set asyncStatus so that PQgetResult will think that
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* what comes back next is the result of a query. See
* below.
*/
conn->asyncStatus = PGASYNC_BUSY;
}
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
/* Look to see if we have more data yet. */
goto keep_going;
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
case CONNECTION_AUTH_OK:
{
/*
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
* Now we expect to hear from the backend. A ReadyForQuery
* message indicates that startup is successful, but we might
* also get an Error message indicating failure. (Notice
* messages indicating nonfatal warnings are also allowed by
In the continuing saga of FE/BE protocol revisions, add reporting of initial values and runtime changes in selected parameters. This gets rid of the need for an initial 'select pg_client_encoding()' query in libpq, bringing us back to one message transmitted in each direction for a standard connection startup. To allow server version to be sent using the same GUC mechanism that handles other parameters, invent the concept of a never-settable GUC parameter: you can 'show server_version' but it's not settable by any GUC input source. Create 'lc_collate' and 'lc_ctype' never-settable parameters so that people can find out these settings without need for pg_controldata. (These side ideas were all discussed some time ago in pgsql-hackers, but not yet implemented.)
2003-04-25 21:45:10 +02:00
* the protocol, as are ParameterStatus and BackendKeyData
* messages.) Easiest way to handle this is to let
* PQgetResult() read the messages. We just have to fake it
* out about the state of the connection, by setting
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
* asyncStatus = PGASYNC_BUSY (done above).
*/
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
Fold PQsetenv working state into PGconn, rather than trying to maintain it in a separate object. There's no value in keeping the state separate, and it creates dangling-pointer problems. Also, remove PQsetenv routines from public API, until and unless they are redesigned to have a safer interface. Since they were never part of the documented API before 7.0, it's unlikely that anyone is calling them.
2000-03-24 02:39:55 +01:00
if (PQisBusy(conn))
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
return PGRES_POLLING_READING;
res = PQgetResult(conn);
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
/*
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* NULL return indicating we have gone to IDLE state is
The attached patch implements some changes that were discussed a couple weeks ago on the hackers and interfaces lists: 1. When the backend sends a NOTICE message and closes the connection (typically, because it was told to by the postmaster after another backend coredumped), libpq will now print the notice and close the connection cleanly. Formerly, the frontend app would usually terminate ungracefully due to a SIGPIPE. (I am not sure if 6.3.2 behaved that way, but the current cvs sources do...) 2. libpq's various printouts to stderr are now fed through a single "notice processor" routine, which can be overridden by the application to direct notices someplace else. This should ease porting libpq to Windows. I also noticed and fixed a problem in PQprint: when sending output to a pager subprocess, it would disable SIGPIPE in case the pager terminates early (this is good) --- but afterwards it reset SIGPIPE to SIG_DFL, rather than restoring the application's prior setting (bad). regards, tom lane
1998-08-09 04:59:33 +02:00
* expected
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
*/
if (res)
{
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
if (res->resultStatus != PGRES_FATAL_ERROR)
Replace appendPQExpBuffer(..., <constant>) with appendPQExpBufferStr Arguably makes the code a bit more readable, and might give a small performance gain. David Rowley
2013-11-18 17:29:01 +01:00
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("unexpected message from server during startup\n"));
Instead of sending application_name as a SET command after the connection is made, include it in the startup-packet options. This makes it work more like every other libpq connection option, in particular it now has the same response to RESET ALL as the rest. This also saves one network round trip for new applications using application_name. The cost is that if the server is pre-8.5, it'll reject the startup packet altogether, forcing us to retry the entire connection cycle. But on balance we shouldn't be optimizing that case in preference to the behavior with a new server, especially when doing so creates visible behavioral oddities. Per discussion.
2009-12-02 05:38:35 +01:00
else if (conn->send_appname &&
(conn->appname || conn->fbappname))
{
/*
* If we tried to send application_name, check to see
Stamp HEAD as 9.0devel, and update various places that were referring to 8.5 (hope I got 'em all). Per discussion, this release will be 9.0 not 8.5.
2010-02-17 05:19:41 +01:00
* if the error is about that --- pre-9.0 servers will
Instead of sending application_name as a SET command after the connection is made, include it in the startup-packet options. This makes it work more like every other libpq connection option, in particular it now has the same response to RESET ALL as the rest. This also saves one network round trip for new applications using application_name. The cost is that if the server is pre-8.5, it'll reject the startup packet altogether, forcing us to retry the entire connection cycle. But on balance we shouldn't be optimizing that case in preference to the behavior with a new server, especially when doing so creates visible behavioral oddities. Per discussion.
2009-12-02 05:38:35 +01:00
* reject it at this stage of the process. If so,
* close the connection and retry without sending
* application_name. We could possibly get a false
* SQLSTATE match here and retry uselessly, but there
* seems no great harm in that; we'll just get the
* same error again if it's unrelated.
*/
const char *sqlstate;
sqlstate = PQresultErrorField(res, PG_DIAG_SQLSTATE);
if (sqlstate &&
strcmp(sqlstate, ERRCODE_APPNAME_UNKNOWN) == 0)
{
PQclear(res);
conn->send_appname = false;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
need_new_connection = true;
Instead of sending application_name as a SET command after the connection is made, include it in the startup-packet options. This makes it work more like every other libpq connection option, in particular it now has the same response to RESET ALL as the rest. This also saves one network round trip for new applications using application_name. The cost is that if the server is pre-8.5, it'll reject the startup packet altogether, forcing us to retry the entire connection cycle. But on balance we shouldn't be optimizing that case in preference to the behavior with a new server, especially when doing so creates visible behavioral oddities. Per discussion.
2009-12-02 05:38:35 +01:00
goto keep_going;
}
}
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
/*
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
* if the resultStatus is FATAL, then conn->errorMessage
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
* already has a copy of the error; needn't copy it back.
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
* But add a newline if it's not there already, since
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
* postmaster error messages may not have one.
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
*/
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
if (conn->errorMessage.len <= 0 ||
conn->errorMessage.data[conn->errorMessage.len - 1] != '\n')
appendPQExpBufferChar(&conn->errorMessage, '\n');
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
PQclear(res);
goto error_return;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
}
Restructure libpq code to remove some duplicity There was some duplicate code to run SHOW transaction_read_only to determine whether the server is read-write or read-only. Reduce it by adding another state to the state machine. Author: Hari Babu Kommi Reviewed-by: Takayuki Tsunakawa, Álvaro Herrera Discussion: https://postgr.es/m/CAJrrPGe_qgdbbN+yBgEVpd+YLHXXjTruzk6RmTMhqrFig+32ag@mail.gmail.com
2019-09-10 17:13:29 +02:00
/* Almost there now ... */
conn->status = CONNECTION_CHECK_TARGET;
goto keep_going;
}
case CONNECTION_CHECK_TARGET:
{
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
/*
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
* If a read-write, read-only, primary, or standby connection
* is required, see if we have one.
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
*/
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
if (conn->target_server_type == SERVER_TYPE_READ_WRITE ||
conn->target_server_type == SERVER_TYPE_READ_ONLY)
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
{
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
bool read_only_server;
libpq: Fix another bug in 721f7bd3cbccaf8c07cad2707826b83f84694832. If we failed to connect to one or more hosts, and then afterwards we find one that fails to be read-write, the latter error message was clobbering any earlier ones. Repair. Mithun Cy, slightly revised by me.
2016-12-05 20:09:54 +01:00
/*
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
* If the server didn't report
* "default_transaction_read_only" or "in_hot_standby" at
* startup, we must determine its state by sending the
Remove server and libpq support for old FE/BE protocol version 2. Protocol version 3 was introduced in PostgreSQL 7.4. There shouldn't be many clients or servers left out there without version 3 support. But as a courtesy, I kept just enough of the old protocol support that we can still send the "unsupported protocol version" error in v2 format, so that old clients can display the message properly. Likewise, libpq still understands v2 ErrorResponse messages when establishing a connection. The impetus to do this now is that I'm working on a patch to COPY FROM, to always prefetch some data. We cannot do that safely with the old protocol, because it requires parsing the input one byte at a time to detect the end-of-copy marker. Reviewed-by: Tom Lane, Alvaro Herrera, John Naylor Discussion: https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cca3b%40iki.fi
2021-03-04 09:45:55 +01:00
* query "SHOW transaction_read_only". This GUC exists in
* all server versions that support 3.0 protocol.
libpq: Fix another bug in 721f7bd3cbccaf8c07cad2707826b83f84694832. If we failed to connect to one or more hosts, and then afterwards we find one that fails to be read-write, the latter error message was clobbering any earlier ones. Repair. Mithun Cy, slightly revised by me.
2016-12-05 20:09:54 +01:00
*/
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
if (conn->default_transaction_read_only == PG_BOOL_UNKNOWN ||
conn->in_hot_standby == PG_BOOL_UNKNOWN)
{
/*
* We use PQsendQueryContinue so that
* conn->errorMessage does not get cleared. We need
* to preserve any error messages related to previous
* hosts we have tried and failed to connect to.
*/
conn->status = CONNECTION_OK;
if (!PQsendQueryContinue(conn,
"SHOW transaction_read_only"))
goto error_return;
/* We'll return to this state when we have the answer */
conn->status = CONNECTION_CHECK_WRITABLE;
return PGRES_POLLING_READING;
}
/* OK, we can make the test */
read_only_server =
(conn->default_transaction_read_only == PG_BOOL_YES ||
conn->in_hot_standby == PG_BOOL_YES);
if ((conn->target_server_type == SERVER_TYPE_READ_WRITE) ?
read_only_server : !read_only_server)
{
/* Wrong server state, reject and try the next host */
if (conn->target_server_type == SERVER_TYPE_READ_WRITE)
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("session is read-only\n"));
else
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("session is not read-only\n"));
/* Close connection politely. */
conn->status = CONNECTION_OK;
sendTerminateConn(conn);
/*
* Try next host if any, but we don't want to consider
* additional addresses for this host.
*/
conn->try_next_host = true;
goto keep_going;
}
}
else if (conn->target_server_type == SERVER_TYPE_PRIMARY ||
conn->target_server_type == SERVER_TYPE_STANDBY ||
conn->target_server_type == SERVER_TYPE_PREFER_STANDBY)
{
/*
* If the server didn't report "in_hot_standby" at
* startup, we must determine its state by sending the
* query "SELECT pg_catalog.pg_is_in_recovery()". Servers
* before 9.0 don't have that function, but by the same
* token they don't have any standby mode, so we may just
* assume the result.
*/
if (conn->sversion < 90000)
conn->in_hot_standby = PG_BOOL_NO;
if (conn->in_hot_standby == PG_BOOL_UNKNOWN)
{
/*
* We use PQsendQueryContinue so that
* conn->errorMessage does not get cleared. We need
* to preserve any error messages related to previous
* hosts we have tried and failed to connect to.
*/
conn->status = CONNECTION_OK;
if (!PQsendQueryContinue(conn,
"SELECT pg_catalog.pg_is_in_recovery()"))
goto error_return;
/* We'll return to this state when we have the answer */
conn->status = CONNECTION_CHECK_STANDBY;
return PGRES_POLLING_READING;
}
/* OK, we can make the test */
if ((conn->target_server_type == SERVER_TYPE_PRIMARY) ?
(conn->in_hot_standby == PG_BOOL_YES) :
(conn->in_hot_standby == PG_BOOL_NO))
{
/* Wrong server state, reject and try the next host */
if (conn->target_server_type == SERVER_TYPE_PRIMARY)
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("server is in hot standby mode\n"));
else
appendPQExpBufferStr(&conn->errorMessage,
libpq_gettext("server is not in hot standby mode\n"));
/* Close connection politely. */
conn->status = CONNECTION_OK;
sendTerminateConn(conn);
/*
* Try next host if any, but we don't want to consider
* additional addresses for this host.
*/
conn->try_next_host = true;
goto keep_going;
}
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
}
In libpq, don't look up all the hostnames at once. Historically, we looked up the target hostname in connectDBStart, so that PQconnectPoll did not need to do DNS name resolution. The patches that added multiple-target-host support to libpq preserved this division of labor; but it's really nonsensical now, because it means that if any one of the target hosts fails to resolve in DNS, the connection fails. That negates the no-single-point-of-failure goal of the feature. Additionally, DNS lookups aren't exactly cheap, but the code did them all even if the first connection attempt succeeds. Hence, rearrange so that PQconnectPoll does the lookups, and only looks up a hostname when it's time to try that host. This does mean that PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid that, you should be using hostaddr, as the documentation has always specified. It seems fairly unlikely that any applications would really care whether the lookup occurs inside PQconnectStart or PQconnectPoll. In addition to calling out that fact explicitly, do some other minor wordsmithing in the docs around the multiple-target-host feature. Since this seems like a bug in the multiple-target-host feature, backpatch to v10 where that was introduced. In the back branches, avoid moving any existing fields of struct pg_conn, just in case any third-party code is looking into that struct. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
2018-08-23 22:39:19 +02:00
/* We can release the address list now. */
release_conn_addrinfo(conn);
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
Clear conn->errorMessage at successful completion of PQconnectdb(). Commits ffa2e4670 and 52a10224e caused libpq's connection-establishment functions to usually leave a nonempty string in the connection's errorMessage buffer, even after a successful connection. While that was intentional on my part, more sober reflection says that it wasn't a great idea: the string would be a bit confusing. Also this broke at least one application that checked for connection success by examining the errorMessage, instead of using PQstatus() as documented. Let's clear the buffer at success exit, restoring the pre-v14 behavior. Discussion: https://postgr.es/m/4170264.1620321747@sss.pgh.pa.us
2021-09-13 22:53:11 +02:00
/*
* Contents of conn->errorMessage are no longer interesting
* (and it seems some clients expect it to be empty after a
* successful connection).
*/
Rearrange libpq's error reporting to avoid duplicated error text. Since commit ffa2e4670, libpq accumulates text in conn->errorMessage across a whole query cycle. In some situations, we may report more than one error event within a cycle: the easiest case to reach is where we report a FATAL error message from the server, and then a bit later we detect loss of connection. Since, historically, each error PGresult bears the entire content of conn->errorMessage, this results in duplication of the FATAL message in any output that concatenates the contents of the PGresults. Accumulation in errorMessage still seems like a good idea, especially in view of the number of places that did ad-hoc error concatenation before ffa2e4670. So to fix this, let's track how much of conn->errorMessage has been read out into error PGresults, and only include new text in later PGresults. The tricky part of that is to be sure that we never discard an error PGresult once made (else we'd risk dropping some text, a problem much worse than duplication). While libpq formerly did that in some code paths, a little bit of rearrangement lets us postpone making an error PGresult at all until we are about to return it. A side benefit of that postponement is that it now becomes practical to return a dummy static PGresult in cases where we hit out-of-memory while trying to manufacture an error PGresult. This eliminates the admittedly-very-rare case where we'd return NULL from PQgetResult, indicating successful query completion, even though what actually happened was an OOM failure. Discussion: https://postgr.es/m/ab4288f8-be5c-57fb-2400-e3e857f53e46@enterprisedb.com
2022-02-18 21:35:15 +01:00
pqClearConnErrorState(conn);
Clear conn->errorMessage at successful completion of PQconnectdb(). Commits ffa2e4670 and 52a10224e caused libpq's connection-establishment functions to usually leave a nonempty string in the connection's errorMessage buffer, even after a successful connection. While that was intentional on my part, more sober reflection says that it wasn't a great idea: the string would be a bit confusing. Also this broke at least one application that checked for connection success by examining the errorMessage, instead of using PQstatus() as documented. Let's clear the buffer at success exit, restoring the pre-v14 behavior. Discussion: https://postgr.es/m/4170264.1620321747@sss.pgh.pa.us
2021-09-13 22:53:11 +02:00
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
/* We are open for business! */
In the continuing saga of FE/BE protocol revisions, add reporting of initial values and runtime changes in selected parameters. This gets rid of the need for an initial 'select pg_client_encoding()' query in libpq, bringing us back to one message transmitted in each direction for a standard connection startup. To allow server version to be sent using the same GUC mechanism that handles other parameters, invent the concept of a never-settable GUC parameter: you can 'show server_version' but it's not settable by any GUC input source. Create 'lc_collate' and 'lc_ctype' never-settable parameters so that people can find out these settings without need for pg_controldata. (These side ideas were all discussed some time ago in pgsql-hackers, but not yet implemented.)
2003-04-25 21:45:10 +02:00
conn->status = CONNECTION_OK;
return PGRES_POLLING_OK;
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
}
libpq: Make target_session_attrs=read-write consume empty result. Otherwise, the leftover empty result can cause problems in some situations. Michael Paquier and Ashutosh Bapat, per a report from Higuchi Daisuke
2017-02-15 17:03:30 +01:00
case CONNECTION_CONSUME:
{
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/*
* This state just makes sure the connection is idle after
* we've obtained the result of a SHOW or SELECT query. Once
* we're clear, return to CONNECTION_CHECK_TARGET state to
* decide what to do next. We must transiently set status =
* CONNECTION_OK in order to use the result-consuming
* subroutines.
*/
libpq: Make target_session_attrs=read-write consume empty result. Otherwise, the leftover empty result can cause problems in some situations. Michael Paquier and Ashutosh Bapat, per a report from Higuchi Daisuke
2017-02-15 17:03:30 +01:00
conn->status = CONNECTION_OK;
if (!PQconsumeInput(conn))
goto error_return;
if (PQisBusy(conn))
{
conn->status = CONNECTION_CONSUME;
return PGRES_POLLING_READING;
}
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/* Call PQgetResult() again until we get a NULL result */
libpq: Make target_session_attrs=read-write consume empty result. Otherwise, the leftover empty result can cause problems in some situations. Michael Paquier and Ashutosh Bapat, per a report from Higuchi Daisuke
2017-02-15 17:03:30 +01:00
res = PQgetResult(conn);
if (res != NULL)
{
PQclear(res);
conn->status = CONNECTION_CONSUME;
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
return PGRES_POLLING_READING;
libpq: Make target_session_attrs=read-write consume empty result. Otherwise, the leftover empty result can cause problems in some situations. Michael Paquier and Ashutosh Bapat, per a report from Higuchi Daisuke
2017-02-15 17:03:30 +01:00
}
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
conn->status = CONNECTION_CHECK_TARGET;
goto keep_going;
libpq: Make target_session_attrs=read-write consume empty result. Otherwise, the leftover empty result can cause problems in some situations. Michael Paquier and Ashutosh Bapat, per a report from Higuchi Daisuke
2017-02-15 17:03:30 +01:00
}
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
case CONNECTION_CHECK_WRITABLE:
{
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/*
* Waiting for result of "SHOW transaction_read_only". We
* must transiently set status = CONNECTION_OK in order to use
* the result-consuming subroutines.
*/
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
conn->status = CONNECTION_OK;
if (!PQconsumeInput(conn))
goto error_return;
if (PQisBusy(conn))
{
conn->status = CONNECTION_CHECK_WRITABLE;
return PGRES_POLLING_READING;
}
res = PQgetResult(conn);
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
if (res && PQresultStatus(res) == PGRES_TUPLES_OK &&
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
PQntuples(res) == 1)
{
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
char *val = PQgetvalue(res, 0, 0);
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/*
* "transaction_read_only = on" proves that at least one
* of default_transaction_read_only and in_hot_standby is
* on, but we don't actually know which. We don't care
* though for the purpose of identifying a read-only
* session, so satisfy the CONNECTION_CHECK_TARGET code by
* claiming they are both on. On the other hand, if it's
* a read-write session, they are certainly both off.
*/
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
if (strncmp(val, "on", 2) == 0)
{
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
conn->default_transaction_read_only = PG_BOOL_YES;
conn->in_hot_standby = PG_BOOL_YES;
}
else
{
conn->default_transaction_read_only = PG_BOOL_NO;
conn->in_hot_standby = PG_BOOL_NO;
}
PQclear(res);
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/* Finish reading messages before continuing */
conn->status = CONNECTION_CONSUME;
goto keep_going;
}
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/* Something went wrong with "SHOW transaction_read_only". */
Remove redundant null pointer checks before PQclear and PQconninfoFree These functions already had the free()-like behavior of handling null pointers as a no-op. But it wasn't documented, so add it explicitly to the documentation, too. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-07-03 20:11:05 +02:00
PQclear(res);
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/* Append error report to conn->errorMessage. */
libpq: Refactor some error messages for easier translation
2021-05-03 08:51:30 +02:00
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("\"%s\" failed\n"),
"SHOW transaction_read_only");
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/* Close connection politely. */
conn->status = CONNECTION_OK;
sendTerminateConn(conn);
/* Try next host. */
conn->try_next_host = true;
goto keep_going;
}
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
case CONNECTION_CHECK_STANDBY:
{
/*
* Waiting for result of "SELECT pg_is_in_recovery()". We
* must transiently set status = CONNECTION_OK in order to use
* the result-consuming subroutines.
*/
conn->status = CONNECTION_OK;
if (!PQconsumeInput(conn))
goto error_return;
if (PQisBusy(conn))
{
conn->status = CONNECTION_CHECK_STANDBY;
return PGRES_POLLING_READING;
}
res = PQgetResult(conn);
if (res && PQresultStatus(res) == PGRES_TUPLES_OK &&
PQntuples(res) == 1)
{
char *val = PQgetvalue(res, 0, 0);
if (strncmp(val, "t", 1) == 0)
conn->in_hot_standby = PG_BOOL_YES;
else
conn->in_hot_standby = PG_BOOL_NO;
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
PQclear(res);
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/* Finish reading messages before continuing */
libpq: Make target_session_attrs=read-write consume empty result. Otherwise, the leftover empty result can cause problems in some situations. Michael Paquier and Ashutosh Bapat, per a report from Higuchi Daisuke
2017-02-15 17:03:30 +01:00
conn->status = CONNECTION_CONSUME;
goto keep_going;
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
}
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/* Something went wrong with "SELECT pg_is_in_recovery()". */
Remove redundant null pointer checks before PQclear and PQconninfoFree These functions already had the free()-like behavior of handling null pointers as a no-op. But it wasn't documented, so add it explicitly to the documentation, too. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-07-03 20:11:05 +02:00
PQclear(res);
Allow multiple hostaddrs to go with multiple hostnames. Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
2017-07-10 11:28:57 +02:00
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/* Append error report to conn->errorMessage. */
libpq: Refactor some error messages for easier translation
2021-05-03 08:51:30 +02:00
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("\"%s\" failed\n"),
"SELECT pg_is_in_recovery()");
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/* Close connection politely. */
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
conn->status = CONNECTION_OK;
sendTerminateConn(conn);
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
/* Try next host. */
conn->try_next_host = true;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
goto keep_going;
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
default:
Add support for multiple error messages from libpq, by simply appending them after each other (since we already add a newline on each, this makes them multiline). Previously a new error would just overwrite the old one, so for example any error caused when trying to connect with SSL enabled would be overwritten by the error message form the non-SSL connection when using sslmode=prefer.
2008-10-27 10:42:31 +01:00
appendPQExpBuffer(&conn->errorMessage,
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
libpq_gettext("invalid connection state %d, "
"probably indicative of memory corruption\n"),
NLS for libpq. Clean up the message formats and change the documentation accordingly.
2001-07-15 15:45:04 +02:00
conn->status);
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
goto error_return;
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
}
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/* Unreachable */
error_return:
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
/*
* We used to close the socket at this point, but that makes it awkward
* for those above us if they wish to remove this socket from their own
* records (an fd_set for example). We'll just have this socket closed
* when PQfinish is called (which is compulsory even after an error, since
* the connection structure must be freed).
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
*/
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
conn->status = CONNECTION_BAD;
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
return PGRES_POLLING_FAILED;
}
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
Add PQping and PQpingParams to libpq to allow detection of the server's status, including a status where the server is running but refuses a postgres connection. Have pg_ctl use this new function. This fixes the case where pg_ctl reports that the server is not running (cannot connect) but in fact it is running.
2010-11-25 19:09:38 +01:00
/*
* internal_ping
Rewrite PQping to be more like what we agreed to last week. Basically, we want to distinguish all cases where the connection was not made from those where it was. A convenient proxy for this is to see if we got a message with a SQLSTATE code back from the postmaster. This presumes that the postmaster will always send us a SQLSTATE in a failure message, which is true for 7.4 and later postmasters in every case except fork failure. (We could possibly complicate the postmaster code to do something about that, but it seems not worth the trouble, especially since pg_ctl's response for that case should be to keep waiting anyway.) If we did get a SQLSTATE from the postmaster, there are basically only two cases, as per last week's discussion: ERRCODE_CANNOT_CONNECT_NOW and everything else. Any other error code implies that the postmaster is in principle willing to accept connections, it just didn't like or couldn't handle this particular request. We want to make a special case for ERRCODE_CANNOT_CONNECT_NOW so that "pg_ctl start -w" knows it should keep waiting. In passing, pick names for the enum constants that are a tad less likely to present collision hazards in future.
2010-11-27 07:30:34 +01:00
* Determine if a server is running and if we can connect to it.
*
* The argument is a connection that's been started, but not completed.
Add PQping and PQpingParams to libpq to allow detection of the server's status, including a status where the server is running but refuses a postgres connection. Have pg_ctl use this new function. This fixes the case where pg_ctl reports that the server is not running (cannot connect) but in fact it is running.
2010-11-25 19:09:38 +01:00
*/
Add missing "static" marker to internal_ping(). Per testing with a compiler that doesn't like that.
2011-03-07 02:04:29 +01:00
static PGPing
Add PQping and PQpingParams to libpq to allow detection of the server's status, including a status where the server is running but refuses a postgres connection. Have pg_ctl use this new function. This fixes the case where pg_ctl reports that the server is not running (cannot connect) but in fact it is running.
2010-11-25 19:09:38 +01:00
internal_ping(PGconn *conn)
{
Rewrite PQping to be more like what we agreed to last week. Basically, we want to distinguish all cases where the connection was not made from those where it was. A convenient proxy for this is to see if we got a message with a SQLSTATE code back from the postmaster. This presumes that the postmaster will always send us a SQLSTATE in a failure message, which is true for 7.4 and later postmasters in every case except fork failure. (We could possibly complicate the postmaster code to do something about that, but it seems not worth the trouble, especially since pg_ctl's response for that case should be to keep waiting anyway.) If we did get a SQLSTATE from the postmaster, there are basically only two cases, as per last week's discussion: ERRCODE_CANNOT_CONNECT_NOW and everything else. Any other error code implies that the postmaster is in principle willing to accept connections, it just didn't like or couldn't handle this particular request. We want to make a special case for ERRCODE_CANNOT_CONNECT_NOW so that "pg_ctl start -w" knows it should keep waiting. In passing, pick names for the enum constants that are a tad less likely to present collision hazards in future.
2010-11-27 07:30:34 +01:00
/* Say "no attempt" if we never got to PQconnectPoll */
if (!conn || !conn->options_valid)
return PQPING_NO_ATTEMPT;
/* Attempt to complete the connection */
if (conn->status != CONNECTION_BAD)
Add PQping and PQpingParams to libpq to allow detection of the server's status, including a status where the server is running but refuses a postgres connection. Have pg_ctl use this new function. This fixes the case where pg_ctl reports that the server is not running (cannot connect) but in fact it is running.
2010-11-25 19:09:38 +01:00
(void) connectDBComplete(conn);
Rewrite PQping to be more like what we agreed to last week. Basically, we want to distinguish all cases where the connection was not made from those where it was. A convenient proxy for this is to see if we got a message with a SQLSTATE code back from the postmaster. This presumes that the postmaster will always send us a SQLSTATE in a failure message, which is true for 7.4 and later postmasters in every case except fork failure. (We could possibly complicate the postmaster code to do something about that, but it seems not worth the trouble, especially since pg_ctl's response for that case should be to keep waiting anyway.) If we did get a SQLSTATE from the postmaster, there are basically only two cases, as per last week's discussion: ERRCODE_CANNOT_CONNECT_NOW and everything else. Any other error code implies that the postmaster is in principle willing to accept connections, it just didn't like or couldn't handle this particular request. We want to make a special case for ERRCODE_CANNOT_CONNECT_NOW so that "pg_ctl start -w" knows it should keep waiting. In passing, pick names for the enum constants that are a tad less likely to present collision hazards in future.
2010-11-27 07:30:34 +01:00
/* Definitely OK if we succeeded */
if (conn->status != CONNECTION_BAD)
return PQPING_OK;
/*
On further testing, PQping also needs an explicit check for AUTH_REQ. The pg_fe_sendauth code might fail if it can't handle the authentication request message type --- if so, ping should still say the server is up.
2010-11-27 08:11:45 +01:00
* Here begins the interesting part of "ping": determine the cause of the
Rewrite PQping to be more like what we agreed to last week. Basically, we want to distinguish all cases where the connection was not made from those where it was. A convenient proxy for this is to see if we got a message with a SQLSTATE code back from the postmaster. This presumes that the postmaster will always send us a SQLSTATE in a failure message, which is true for 7.4 and later postmasters in every case except fork failure. (We could possibly complicate the postmaster code to do something about that, but it seems not worth the trouble, especially since pg_ctl's response for that case should be to keep waiting anyway.) If we did get a SQLSTATE from the postmaster, there are basically only two cases, as per last week's discussion: ERRCODE_CANNOT_CONNECT_NOW and everything else. Any other error code implies that the postmaster is in principle willing to accept connections, it just didn't like or couldn't handle this particular request. We want to make a special case for ERRCODE_CANNOT_CONNECT_NOW so that "pg_ctl start -w" knows it should keep waiting. In passing, pick names for the enum constants that are a tad less likely to present collision hazards in future.
2010-11-27 07:30:34 +01:00
* failure in sufficient detail to decide what to return. We do not want
* to report that the server is not up just because we didn't have a valid
On further testing, PQping also needs an explicit check for AUTH_REQ. The pg_fe_sendauth code might fail if it can't handle the authentication request message type --- if so, ping should still say the server is up.
2010-11-27 08:11:45 +01:00
* password, for example. In fact, any sort of authentication request
* implies the server is up. (We need this check since the libpq side of
* things might have pulled the plug on the connection before getting an
* error as such from the postmaster.)
*/
if (conn->auth_req_received)
return PQPING_OK;
/*
Rewrite PQping to be more like what we agreed to last week. Basically, we want to distinguish all cases where the connection was not made from those where it was. A convenient proxy for this is to see if we got a message with a SQLSTATE code back from the postmaster. This presumes that the postmaster will always send us a SQLSTATE in a failure message, which is true for 7.4 and later postmasters in every case except fork failure. (We could possibly complicate the postmaster code to do something about that, but it seems not worth the trouble, especially since pg_ctl's response for that case should be to keep waiting anyway.) If we did get a SQLSTATE from the postmaster, there are basically only two cases, as per last week's discussion: ERRCODE_CANNOT_CONNECT_NOW and everything else. Any other error code implies that the postmaster is in principle willing to accept connections, it just didn't like or couldn't handle this particular request. We want to make a special case for ERRCODE_CANNOT_CONNECT_NOW so that "pg_ctl start -w" knows it should keep waiting. In passing, pick names for the enum constants that are a tad less likely to present collision hazards in future.
2010-11-27 07:30:34 +01:00
* If we failed to get any ERROR response from the postmaster, report
* PQPING_NO_RESPONSE. This result could be somewhat misleading for a
* pre-7.4 server, since it won't send back a SQLSTATE, but those are long
* out of support. Another corner case where the server could return a
Fix inconsistencies and typos in the tree, take 9 This addresses more issues with code comments, variable names and unreferenced variables. Author: Alexander Lakhin Discussion: https://postgr.es/m/7ab243e0-116d-3e44-d120-76b3df7abefd@gmail.com
2019-08-05 05:14:58 +02:00
* failure without a SQLSTATE is fork failure, but PQPING_NO_RESPONSE
* isn't totally unreasonable for that anyway. We expect that every other
Rewrite PQping to be more like what we agreed to last week. Basically, we want to distinguish all cases where the connection was not made from those where it was. A convenient proxy for this is to see if we got a message with a SQLSTATE code back from the postmaster. This presumes that the postmaster will always send us a SQLSTATE in a failure message, which is true for 7.4 and later postmasters in every case except fork failure. (We could possibly complicate the postmaster code to do something about that, but it seems not worth the trouble, especially since pg_ctl's response for that case should be to keep waiting anyway.) If we did get a SQLSTATE from the postmaster, there are basically only two cases, as per last week's discussion: ERRCODE_CANNOT_CONNECT_NOW and everything else. Any other error code implies that the postmaster is in principle willing to accept connections, it just didn't like or couldn't handle this particular request. We want to make a special case for ERRCODE_CANNOT_CONNECT_NOW so that "pg_ctl start -w" knows it should keep waiting. In passing, pick names for the enum constants that are a tad less likely to present collision hazards in future.
2010-11-27 07:30:34 +01:00
* failure case in a modern server will produce a report with a SQLSTATE.
*
* NOTE: whenever we get around to making libpq generate SQLSTATEs for
* client-side errors, we should either not store those into
* last_sqlstate, or add an extra flag so we can tell client-side errors
* apart from server-side ones.
*/
if (strlen(conn->last_sqlstate) != 5)
return PQPING_NO_RESPONSE;
/*
Fix comment in fe-connect.c about PQping and pg_ctl Since f13ea95f, pg_ctl does not use PQping(), but one comment did not get the call. Author: Euler Taveira Discussion: https://postgr.es/m/4b1deb4a-2771-416d-9710-ccd2fa66f058@www.fastmail.com
2022-01-07 08:05:31 +01:00
* Report PQPING_REJECT if server says it's not accepting connections.
Rewrite PQping to be more like what we agreed to last week. Basically, we want to distinguish all cases where the connection was not made from those where it was. A convenient proxy for this is to see if we got a message with a SQLSTATE code back from the postmaster. This presumes that the postmaster will always send us a SQLSTATE in a failure message, which is true for 7.4 and later postmasters in every case except fork failure. (We could possibly complicate the postmaster code to do something about that, but it seems not worth the trouble, especially since pg_ctl's response for that case should be to keep waiting anyway.) If we did get a SQLSTATE from the postmaster, there are basically only two cases, as per last week's discussion: ERRCODE_CANNOT_CONNECT_NOW and everything else. Any other error code implies that the postmaster is in principle willing to accept connections, it just didn't like or couldn't handle this particular request. We want to make a special case for ERRCODE_CANNOT_CONNECT_NOW so that "pg_ctl start -w" knows it should keep waiting. In passing, pick names for the enum constants that are a tad less likely to present collision hazards in future.
2010-11-27 07:30:34 +01:00
*/
if (strcmp(conn->last_sqlstate, ERRCODE_CANNOT_CONNECT_NOW) == 0)
return PQPING_REJECT;
/*
* Any other SQLSTATE can be taken to indicate that the server is up.
* Presumably it didn't like our username, password, or database name; or
* perhaps it had some transient failure, but that should not be taken as
* meaning "it's down".
*/
return PQPING_OK;
Add PQping and PQpingParams to libpq to allow detection of the server's status, including a status where the server is running but refuses a postgres connection. Have pg_ctl use this new function. This fixes the case where pg_ctl reports that the server is not running (cannot connect) but in fact it is running.
2010-11-25 19:09:38 +01:00
}
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
/*
* makeEmptyPGconn
* - create a PGconn data structure with (as yet) no interesting data
*/
static PGconn *
makeEmptyPGconn(void)
{
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
PGconn *conn;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
here are the patches for psql on Win32: psql4win32.patch - changes in the psql source code psql-ref.patch - changes in the documentation psql-ref.sgml (for new builtin variable WIN32_CONSOLE) To apply them use "patch -p 1" in the root directory of the postgres source directory. These patches fix the following problems of psql on Win32 (all changes only have effect #ifdef WIN32): a) Problem: Static library libpq.a did not work Solution: Added WSAStartup() in fe-connect.c b) Problem: Secret Password was echoed by psql Solution: Password echoing disabled in sprompt.c c) Problem: 8bit characters were displayed/interpreted wrong in psql This is due to the fact that the Win32 "console" uses a different encoding than the rest of the Windows system Solution: Introduced a new psql variable WIN32_CONSOLE When set with "\set WIN32_console", the function OemToChar() is applied after reading input and CharToOem() before displaying Output Christoph Dalitz
2003-07-27 05:32:26 +02:00
#ifdef WIN32
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
Add comments on WSAStartup usage.
2005-05-05 18:40:42 +02:00
/*
In libpq for Windows, call WSAStartup once and WSACleanup not at all. The Windows documentation insists that every WSAStartup call should have a matching WSACleanup call. However, if that ever had actual relevance, it wasn't in this century. Every remotely-modern Windows kernel is capable of cleaning up when a process exits without doing that, and must be so to avoid resource leaks in case of a process crash. Moreover, Postgres backends have done WSAStartup without WSACleanup since commit 4cdf51e64 in 2004, and we've never seen any indication of a problem with that. libpq's habit of doing WSAStartup during connection start and WSACleanup during shutdown is also rather inefficient, since a series of non-overlapping connection requests leads to repeated, quite expensive DLL unload/reload cycles. We document a workaround for that (having the application call WSAStartup for itself), but that's just a kluge. It's also worth noting that it's far from uncommon for applications to exit without doing PQfinish, and we've not heard reports of trouble from that either. However, the real reason for acting on this is that recent experiments by Alexander Lakhin suggest that calling WSACleanup during PQfinish might be triggering the symptom we occasionally see that a process using libpq fails to emit expected stdio output. Therefore, let's change libpq so that it calls WSAStartup only once per process, during the first connection attempt, and never calls WSACleanup at all. While at it, get rid of the only other WSACleanup call in our code tree, in pg_dump/parallel.c; that presumably is equally useless. If this proves to suppress the fairly-common ecpg test failures we see on Windows, I'll back-patch, but for now let's just do it in HEAD and see what happens. Discussion: https://postgr.es/m/ac976d8c-03df-d6b8-025c-15a2de8d9af1@postgrespro.ru
2020-10-17 22:53:48 +02:00
* Make sure socket support is up and running in this process.
*
* Note: the Windows documentation says that we should eventually do a
* matching WSACleanup() call, but experience suggests that that is at
* least as likely to cause problems as fix them. So we don't.
Add comments on WSAStartup usage.
2005-05-05 18:40:42 +02:00
*/
In libpq for Windows, call WSAStartup once and WSACleanup not at all. The Windows documentation insists that every WSAStartup call should have a matching WSACleanup call. However, if that ever had actual relevance, it wasn't in this century. Every remotely-modern Windows kernel is capable of cleaning up when a process exits without doing that, and must be so to avoid resource leaks in case of a process crash. Moreover, Postgres backends have done WSAStartup without WSACleanup since commit 4cdf51e64 in 2004, and we've never seen any indication of a problem with that. libpq's habit of doing WSAStartup during connection start and WSACleanup during shutdown is also rather inefficient, since a series of non-overlapping connection requests leads to repeated, quite expensive DLL unload/reload cycles. We document a workaround for that (having the application call WSAStartup for itself), but that's just a kluge. It's also worth noting that it's far from uncommon for applications to exit without doing PQfinish, and we've not heard reports of trouble from that either. However, the real reason for acting on this is that recent experiments by Alexander Lakhin suggest that calling WSACleanup during PQfinish might be triggering the symptom we occasionally see that a process using libpq fails to emit expected stdio output. Therefore, let's change libpq so that it calls WSAStartup only once per process, during the first connection attempt, and never calls WSACleanup at all. While at it, get rid of the only other WSACleanup call in our code tree, in pg_dump/parallel.c; that presumably is equally useless. If this proves to suppress the fairly-common ecpg test failures we see on Windows, I'll back-patch, but for now let's just do it in HEAD and see what happens. Discussion: https://postgr.es/m/ac976d8c-03df-d6b8-025c-15a2de8d9af1@postgrespro.ru
2020-10-17 22:53:48 +02:00
static bool wsastartup_done = false;
here are the patches for psql on Win32: psql4win32.patch - changes in the psql source code psql-ref.patch - changes in the documentation psql-ref.sgml (for new builtin variable WIN32_CONSOLE) To apply them use "patch -p 1" in the root directory of the postgres source directory. These patches fix the following problems of psql on Win32 (all changes only have effect #ifdef WIN32): a) Problem: Static library libpq.a did not work Solution: Added WSAStartup() in fe-connect.c b) Problem: Secret Password was echoed by psql Solution: Password echoing disabled in sprompt.c c) Problem: 8bit characters were displayed/interpreted wrong in psql This is due to the fact that the Win32 "console" uses a different encoding than the rest of the Windows system Solution: Introduced a new psql variable WIN32_CONSOLE When set with "\set WIN32_console", the function OemToChar() is applied after reading input and CharToOem() before displaying Output Christoph Dalitz
2003-07-27 05:32:26 +02:00
In libpq for Windows, call WSAStartup once and WSACleanup not at all. The Windows documentation insists that every WSAStartup call should have a matching WSACleanup call. However, if that ever had actual relevance, it wasn't in this century. Every remotely-modern Windows kernel is capable of cleaning up when a process exits without doing that, and must be so to avoid resource leaks in case of a process crash. Moreover, Postgres backends have done WSAStartup without WSACleanup since commit 4cdf51e64 in 2004, and we've never seen any indication of a problem with that. libpq's habit of doing WSAStartup during connection start and WSACleanup during shutdown is also rather inefficient, since a series of non-overlapping connection requests leads to repeated, quite expensive DLL unload/reload cycles. We document a workaround for that (having the application call WSAStartup for itself), but that's just a kluge. It's also worth noting that it's far from uncommon for applications to exit without doing PQfinish, and we've not heard reports of trouble from that either. However, the real reason for acting on this is that recent experiments by Alexander Lakhin suggest that calling WSACleanup during PQfinish might be triggering the symptom we occasionally see that a process using libpq fails to emit expected stdio output. Therefore, let's change libpq so that it calls WSAStartup only once per process, during the first connection attempt, and never calls WSACleanup at all. While at it, get rid of the only other WSACleanup call in our code tree, in pg_dump/parallel.c; that presumably is equally useless. If this proves to suppress the fairly-common ecpg test failures we see on Windows, I'll back-patch, but for now let's just do it in HEAD and see what happens. Discussion: https://postgr.es/m/ac976d8c-03df-d6b8-025c-15a2de8d9af1@postgrespro.ru
2020-10-17 22:53:48 +02:00
if (!wsastartup_done)
{
WSADATA wsaData;
Update the Winsock API version requested by libpq. According to Microsoft's documentation, 2.2 has been the current version since Windows 98 or so. Moreover, that's what the Postgres backend has been requesting since 2004 (cf commit 4cdf51e64). So there seems no reason for libpq to keep asking for 1.1. Bring thread_test along, too, so that we're uniformly asking for 2.2 in all our WSAStartup calls. It's not clear whether there's any point in back-patching this, so for now I didn't. Discussion: https://postgr.es/m/132799.1602960277@sss.pgh.pa.us
2020-10-18 18:56:43 +02:00
if (WSAStartup(MAKEWORD(2, 2), &wsaData) != 0)
In libpq for Windows, call WSAStartup once and WSACleanup not at all. The Windows documentation insists that every WSAStartup call should have a matching WSACleanup call. However, if that ever had actual relevance, it wasn't in this century. Every remotely-modern Windows kernel is capable of cleaning up when a process exits without doing that, and must be so to avoid resource leaks in case of a process crash. Moreover, Postgres backends have done WSAStartup without WSACleanup since commit 4cdf51e64 in 2004, and we've never seen any indication of a problem with that. libpq's habit of doing WSAStartup during connection start and WSACleanup during shutdown is also rather inefficient, since a series of non-overlapping connection requests leads to repeated, quite expensive DLL unload/reload cycles. We document a workaround for that (having the application call WSAStartup for itself), but that's just a kluge. It's also worth noting that it's far from uncommon for applications to exit without doing PQfinish, and we've not heard reports of trouble from that either. However, the real reason for acting on this is that recent experiments by Alexander Lakhin suggest that calling WSACleanup during PQfinish might be triggering the symptom we occasionally see that a process using libpq fails to emit expected stdio output. Therefore, let's change libpq so that it calls WSAStartup only once per process, during the first connection attempt, and never calls WSACleanup at all. While at it, get rid of the only other WSACleanup call in our code tree, in pg_dump/parallel.c; that presumably is equally useless. If this proves to suppress the fairly-common ecpg test failures we see on Windows, I'll back-patch, but for now let's just do it in HEAD and see what happens. Discussion: https://postgr.es/m/ac976d8c-03df-d6b8-025c-15a2de8d9af1@postgrespro.ru
2020-10-17 22:53:48 +02:00
return NULL;
wsastartup_done = true;
}
/* Forget any earlier error */
here are the patches for psql on Win32: psql4win32.patch - changes in the psql source code psql-ref.patch - changes in the documentation psql-ref.sgml (for new builtin variable WIN32_CONSOLE) To apply them use "patch -p 1" in the root directory of the postgres source directory. These patches fix the following problems of psql on Win32 (all changes only have effect #ifdef WIN32): a) Problem: Static library libpq.a did not work Solution: Added WSAStartup() in fe-connect.c b) Problem: Secret Password was echoed by psql Solution: Password echoing disabled in sprompt.c c) Problem: 8bit characters were displayed/interpreted wrong in psql This is due to the fact that the Win32 "console" uses a different encoding than the rest of the Windows system Solution: Introduced a new psql variable WIN32_CONSOLE When set with "\set WIN32_console", the function OemToChar() is applied after reading input and CharToOem() before displaying Output Christoph Dalitz
2003-07-27 05:32:26 +02:00
WSASetLastError(0);
In libpq for Windows, call WSAStartup once and WSACleanup not at all. The Windows documentation insists that every WSAStartup call should have a matching WSACleanup call. However, if that ever had actual relevance, it wasn't in this century. Every remotely-modern Windows kernel is capable of cleaning up when a process exits without doing that, and must be so to avoid resource leaks in case of a process crash. Moreover, Postgres backends have done WSAStartup without WSACleanup since commit 4cdf51e64 in 2004, and we've never seen any indication of a problem with that. libpq's habit of doing WSAStartup during connection start and WSACleanup during shutdown is also rather inefficient, since a series of non-overlapping connection requests leads to repeated, quite expensive DLL unload/reload cycles. We document a workaround for that (having the application call WSAStartup for itself), but that's just a kluge. It's also worth noting that it's far from uncommon for applications to exit without doing PQfinish, and we've not heard reports of trouble from that either. However, the real reason for acting on this is that recent experiments by Alexander Lakhin suggest that calling WSACleanup during PQfinish might be triggering the symptom we occasionally see that a process using libpq fails to emit expected stdio output. Therefore, let's change libpq so that it calls WSAStartup only once per process, during the first connection attempt, and never calls WSACleanup at all. While at it, get rid of the only other WSACleanup call in our code tree, in pg_dump/parallel.c; that presumably is equally useless. If this proves to suppress the fairly-common ecpg test failures we see on Windows, I'll back-patch, but for now let's just do it in HEAD and see what happens. Discussion: https://postgr.es/m/ac976d8c-03df-d6b8-025c-15a2de8d9af1@postgrespro.ru
2020-10-17 22:53:48 +02:00
#endif /* WIN32 */
here are the patches for psql on Win32: psql4win32.patch - changes in the psql source code psql-ref.patch - changes in the documentation psql-ref.sgml (for new builtin variable WIN32_CONSOLE) To apply them use "patch -p 1" in the root directory of the postgres source directory. These patches fix the following problems of psql on Win32 (all changes only have effect #ifdef WIN32): a) Problem: Static library libpq.a did not work Solution: Added WSAStartup() in fe-connect.c b) Problem: Secret Password was echoed by psql Solution: Password echoing disabled in sprompt.c c) Problem: 8bit characters were displayed/interpreted wrong in psql This is due to the fact that the Win32 "console" uses a different encoding than the rest of the Windows system Solution: Introduced a new psql variable WIN32_CONSOLE When set with "\set WIN32_console", the function OemToChar() is applied after reading input and CharToOem() before displaying Output Christoph Dalitz
2003-07-27 05:32:26 +02:00
Code review for sslmode patch: eliminate memory leak, avoid giving a completely useless error message in 'allow' case, don't retry connection at the sendauth stage (by then the server will either let us in or not, no point in wasting cycles on another try in the other SSL state).
2003-08-01 23:27:27 +02:00
conn = (PGconn *) malloc(sizeof(PGconn));
if (conn == NULL)
return conn;
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
/* Zero all pointers and booleans */
More janitorial work: remove the explicit casting of NULL literals to a pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
2004-01-07 19:56:30 +01:00
MemSet(conn, 0, sizeof(PGconn));
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
Replace libpq's "row processor" API with a "single row" mode. After taking awhile to digest the row-processor feature that was added to libpq in commit 92785dac2ee7026948962cd61c4cd84a2d052772, we've concluded it is over-complicated and too hard to use. Leave the core infrastructure changes in place (that is, there's still a row processor function inside libpq), but remove the exposed API pieces, and instead provide a "single row" mode switch that causes PQgetResult to return one row at a time in separate PGresult objects. This approach incurs more overhead than proper use of a row processor callback would, since construction of a PGresult per row adds extra cycles. However, it is far easier to use and harder to break. The single-row mode still affords applications the primary benefit that the row processor API was meant to provide, namely not having to accumulate large result sets in memory before processing them. Preliminary testing suggests that we can probably buy back most of the extra cycles by micro-optimizing construction of the extra results, but that task will be left for another day. Marko Kreen
2012-08-02 19:10:30 +02:00
/* install default notice hooks */
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
conn->noticeHooks.noticeRec = defaultNoticeReceiver;
conn->noticeHooks.noticeProc = defaultNoticeProcessor;
Add a "row processor" API to libpq for better handling of large results. Traditionally libpq has collected an entire query result before passing it back to the application. That provides a simple and transactional API, but it's pretty inefficient for large result sets. This patch allows the application to process each row on-the-fly instead of accumulating the rows into the PGresult. Error recovery becomes a bit more complex, but often that tradeoff is well worth making. Kyotaro Horiguchi, reviewed by Marko Kreen and Tom Lane
2012-04-05 00:27:56 +02:00
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
conn->status = CONNECTION_BAD;
conn->asyncStatus = PGASYNC_IDLE;
Implement pipeline mode in libpq Pipeline mode in libpq lets an application avoid the Sync messages in the FE/BE protocol that are implicit in the old libpq API after each query. The application can then insert Sync at its leisure with a new libpq function PQpipelineSync. This can lead to substantial reductions in query latency. Co-authored-by: Craig Ringer <craig.ringer@enterprisedb.com> Co-authored-by: Matthieu Garrigues <matthieu.garrigues@gmail.com> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Aya Iwata <iwata.aya@jp.fujitsu.com> Reviewed-by: Daniel Vérité <daniel@manitou-mail.org> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Kirk Jamison <k.jamison@fujitsu.com> Reviewed-by: Michael Paquier <michael.paquier@gmail.com> Reviewed-by: Nikhil Sontakke <nikhils@2ndquadrant.com> Reviewed-by: Vaishnavi Prabakaran <VaishnaviP@fast.au.fujitsu.com> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Discussion: https://postgr.es/m/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com Discussion: https://postgr.es/m/CAJkzx4T5E-2cQe3dtv2R78dYFvz+in8PY7A8MArvLhs_pg75gg@mail.gmail.com
2021-03-15 22:13:42 +01:00
conn->pipelineStatus = PQ_PIPELINE_OFF;
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
conn->xactStatus = PQTRANS_IDLE;
Add positive defense against trying to connect when the connection option state hasn't been fully set up. This is possible via PQreset() and might occur in other code paths too, so a state flag seems the most robust solution. Per report from Arturs Zoldners.
2006-02-13 23:33:57 +01:00
conn->options_valid = false;
conn->nonblocking = false;
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
conn->client_encoding = PG_SQL_ASCII;
Modify libpq's string-escaping routines to be aware of encoding considerations and standard_conforming_strings. The encoding changes are needed for proper escaping in multibyte encodings, as per the SQL-injection vulnerabilities noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied to the server to ensure that it rejects queries that may have been corrupted by attempted SQL injection, but this merely guarantees that unpatched clients will fail rather than allow injection. An actual fix requires changing the client-side code. While at it we have also fixed these routines to understand about standard_conforming_strings, so that the upcoming changeover to SQL-spec string syntax can be somewhat transparent to client code. Since the existing API of PQescapeString and PQescapeBytea provides no way to inform them which settings are in use, these functions are now deprecated in favor of new functions PQescapeStringConn and PQescapeByteaConn. The new functions take the PGconn to which the string will be sent as an additional parameter, and look inside the connection structure to determine what to do. So as to provide some functionality for clients using the old functions, libpq stores the latest encoding and standard_conforming_strings values received from the backend in static variables, and the old functions consult these variables. This will work reliably in clients using only one Postgres connection at a time, or even multiple connections if they all use the same encoding and string syntax settings; which should cover many practical scenarios. Clients that use homebrew escaping methods, such as PHP's addslashes() function or even hardwired regexp substitution, will require extra effort to fix :-(. It is strongly recommended that such code be replaced by use of PQescapeStringConn/PQescapeByteaConn if at all feasible.
2006-05-21 22:19:23 +02:00
conn->std_strings = false; /* unless server says differently */
Extend the abilities of libpq's target_session_attrs parameter. In addition to the existing options of "any" and "read-write", we now support "read-only", "primary", "standby", and "prefer-standby". "read-write" retains its previous meaning of "transactions are read-write by default", and "read-only" inverts that. The other three modes test specifically for hot-standby status, which is not quite the same thing. (Setting default_transaction_read_only on a primary server renders it read-only to this logic, but not a standby.) Furthermore, if talking to a v14 or later server, no extra network round trip is needed to detect the session's status; the GUC_REPORT variables delivered by the server are enough. When talking to an older server, a SHOW or SELECT query is issued to detect session read-only-ness or server hot-standby state, as needed. Haribabu Kommi, Greg Nancarrow, Vignesh C, Tom Lane; reviewed at various times by Laurenz Albe, Takayuki Tsunakawa, Peter Smith. Discussion: https://postgr.es/m/CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com
2021-03-03 02:17:45 +01:00
conn->default_transaction_read_only = PG_BOOL_UNKNOWN;
conn->in_hot_standby = PG_BOOL_UNKNOWN;
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
conn->verbosity = PQERRORS_DEFAULT;
Rearrange the handling of error context reports. Remove the code in plpgsql that suppressed the innermost line of CONTEXT for messages emitted by RAISE commands. That was never more than a quick backwards-compatibility hack, and it's pretty silly in cases where the RAISE is nested in several levels of function. What's more, it violated our design theory that verbosity of error reports should be controlled on the client side not the server side. To alleviate the resulting noise increase, introduce a feature in libpq and psql whereby the CONTEXT field of messages can be suppressed, either always or only for non-error messages. Printing CONTEXT for errors only is now their default behavior. The actual code changes here are pretty small, but the effects on the regression test outputs are widespread. I had to edit some of the alternative expected outputs by hand; hopefully the buildfarm will soon find anything I fat-fingered. In passing, fix up (again) the output line counts in psql's various help displays. Add some commentary about how to verify them. Pavel Stehule, reviewed by Petr Jelínek, Jeevan Chalke, and others
2015-09-05 17:58:20 +02:00
conn->show_context = PQSHOW_CONTEXT_ERRORS;
libpq: use pgsocket for socket values, for portability Previously, 'int' was used for socket values in libpq, but socket values are unsigned on Windows. This is a style correction. Initial patch and previous PGINVALID_SOCKET initial patch by Joel Jacobson, modified by me Report from PVS-Studio
2014-04-17 01:46:51 +02:00
conn->sock = PGINVALID_SOCKET;
Initialize conn->Pfdebug to NULL when creating a connection Failing to do this can cause a crash, and I suspect is what has happened with a buildfarm member reporting mysterious failures. This is an ancient bug, but I'm not backpatching since evidently nobody cares about PQtrace in older releases. Discussion: https://postgr.es/m/3333908.1617227066@sss.pgh.pa.us
2021-04-01 00:16:58 +02:00
conn->Pfdebug = NULL;
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
/*
Second round of FE/BE protocol changes. Frontend->backend messages now have length counts, and COPY IN data is packetized into messages.
2003-04-19 02:02:30 +02:00
* We try to send at least 8K at a time, which is the usual size of pipe
* buffers on Unix systems. That way, when we are sending a large amount
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
* of data, we avoid incurring extra kernel context swaps for partial
Second round of FE/BE protocol changes. Frontend->backend messages now have length counts, and COPY IN data is packetized into messages.
2003-04-19 02:02:30 +02:00
* bufferloads. The output buffer is initially made 16K in size, and we
* try to dump it after accumulating 8K.
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
*
* With the same goal of minimizing context swaps, the input buffer will
* be enlarged anytime it has less than 8K free, so we initially allocate
* twice that.
*/
conn->inBufSize = 16 * 1024;
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
conn->inBuffer = (char *) malloc(conn->inBufSize);
Second round of FE/BE protocol changes. Frontend->backend messages now have length counts, and COPY IN data is packetized into messages.
2003-04-19 02:02:30 +02:00
conn->outBufSize = 16 * 1024;
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
conn->outBuffer = (char *) malloc(conn->outBufSize);
Add a "row processor" API to libpq for better handling of large results. Traditionally libpq has collected an entire query result before passing it back to the application. That provides a simple and transactional API, but it's pretty inefficient for large result sets. This patch allows the application to process each row on-the-fly instead of accumulating the rows into the PGresult. Error recovery becomes a bit more complex, but often that tradeoff is well worth making. Kyotaro Horiguchi, reviewed by Marko Kreen and Tom Lane
2012-04-05 00:27:56 +02:00
conn->rowBufLen = 32;
conn->rowBuf = (PGdataValue *) malloc(conn->rowBufLen * sizeof(PGdataValue));
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
initPQExpBuffer(&conn->errorMessage);
initPQExpBuffer(&conn->workBuffer);
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
if (conn->inBuffer == NULL ||
conn->outBuffer == NULL ||
Add a "row processor" API to libpq for better handling of large results. Traditionally libpq has collected an entire query result before passing it back to the application. That provides a simple and transactional API, but it's pretty inefficient for large result sets. This patch allows the application to process each row on-the-fly instead of accumulating the rows into the PGresult. Error recovery becomes a bit more complex, but often that tradeoff is well worth making. Kyotaro Horiguchi, reviewed by Marko Kreen and Tom Lane
2012-04-05 00:27:56 +02:00
conn->rowBuf == NULL ||
Adjust the behavior of the PQExpBuffer code to make it have well-defined results (ie, an empty "broken" buffer) if memory overrun occurs anywhere along the way to filling the buffer. The previous coding would just silently discard portions of the intended buffer contents, as exhibited in trouble report from Sam Mason. Also, tweak psql's main loop to correctly detect and report such overruns. There's probably much more that should be done in this line, but this is a start.
2008-11-26 01:26:23 +01:00
PQExpBufferBroken(&conn->errorMessage) ||
PQExpBufferBroken(&conn->workBuffer))
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
{
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
/* out of memory already :-( */
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
freePGconn(conn);
conn = NULL;
}
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
return conn;
}
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*
* freePGconn
Fix up closePGconn() so that PQreset() will work on GSSAPI/SSPI connections; the patch for those features put its cleanup code into freePGconn() which is really the wrong place. Remove redundant code from freePGconn() and add comments in hopes of preventing similar mistakes in future. Noticed while trying (futilely) to reproduce bug #3902.
2008-01-29 03:06:30 +01:00
* - free an idle (closed) PGconn data structure
Fix libpq memory leak during PQreset() --- closePGconn() was not freeing all transient state of the PGconn object.
2005-07-13 17:25:55 +02:00
*
Fix up closePGconn() so that PQreset() will work on GSSAPI/SSPI connections; the patch for those features put its cleanup code into freePGconn() which is really the wrong place. Remove redundant code from freePGconn() and add comments in hopes of preventing similar mistakes in future. Noticed while trying (futilely) to reproduce bug #3902.
2008-01-29 03:06:30 +01:00
* NOTE: this should not overlap any functionality with closePGconn().
* Clearing/resetting of transient state belongs there; what we do here is
* release data that is to be held for the life of the PGconn structure.
* If a value ought to be cleared/freed during PQreset(), do it there not here.
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
static void
freePGconn(PGconn *conn)
{
Add an "events" system to libpq, whereby applications can get callbacks that enable them to manage private data associated with PGconns and PGresults. Andrew Chernow and Merlin Moncure
2008-09-17 06:31:08 +02:00
/* let any event procs clean up their state data */
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
for (int i = 0; i < conn->nEvents; i++)
Add an "events" system to libpq, whereby applications can get callbacks that enable them to manage private data associated with PGconns and PGresults. Andrew Chernow and Merlin Moncure
2008-09-17 06:31:08 +02:00
{
PGEventConnDestroy evt;
evt.conn = conn;
(void) conn->events[i].proc(PGEVT_CONNDESTROY, &evt,
conn->events[i].passThrough);
free(conn->events[i].name);
}
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
/* clean up pg_conn_host structures */
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
for (int i = 0; i < conn->nconnhost; ++i)
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->connhost[i].host);
free(conn->connhost[i].hostaddr);
free(conn->connhost[i].port);
if (conn->connhost[i].password != NULL)
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
explicit_bzero(conn->connhost[i].password, strlen(conn->connhost[i].password));
free(conn->connhost[i].password);
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
}
}
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->connhost);
free(conn->client_encoding_initial);
free(conn->events);
free(conn->pghost);
free(conn->pghostaddr);
free(conn->pgport);
free(conn->connect_timeout);
free(conn->pgtcp_user_timeout);
free(conn->pgoptions);
free(conn->appname);
free(conn->fbappname);
free(conn->dbName);
free(conn->replication);
free(conn->pguser);
From: Bryan Henderson <bryanh@giraffe-data.com> Here's a fix for a tiny memory leak in PQsetdb/PQfinish. (Analysis of a running program indicates there are several others, but this is the only obvious one I saw in the code).
1998-04-21 06:00:06 +02:00
if (conn->pgpass)
Use explicit_bzero Use the explicit_bzero() function in places where it is important that security information such as passwords is cleared from memory. There might be other places where it could be useful; this is just an initial collection. For platforms that don't have explicit_bzero(), provide various fallback implementations. (explicit_bzero() itself isn't standard, but as Linux/glibc, FreeBSD, and OpenBSD have it, it's the most common spelling, so it makes sense to make that the invocation point.) Discussion: https://www.postgresql.org/message-id/flat/42d26bde-5d5b-c90d-87ae-6cab875f73be%402ndquadrant.com
2019-09-05 08:15:58 +02:00
{
explicit_bzero(conn->pgpass, strlen(conn->pgpass));
From: Bryan Henderson <bryanh@giraffe-data.com> Here's a fix for a tiny memory leak in PQsetdb/PQfinish. (Analysis of a running program indicates there are several others, but this is the only obvious one I saw in the code).
1998-04-21 06:00:06 +02:00
free(conn->pgpass);
Use explicit_bzero Use the explicit_bzero() function in places where it is important that security information such as passwords is cleared from memory. There might be other places where it could be useful; this is just an initial collection. For platforms that don't have explicit_bzero(), provide various fallback implementations. (explicit_bzero() itself isn't standard, but as Linux/glibc, FreeBSD, and OpenBSD have it, it's the most common spelling, so it makes sense to make that the invocation point.) Discussion: https://www.postgresql.org/message-id/flat/42d26bde-5d5b-c90d-87ae-6cab875f73be%402ndquadrant.com
2019-09-05 08:15:58 +02:00
}
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->pgpassfile);
free(conn->channel_binding);
free(conn->keepalives);
free(conn->keepalives_idle);
free(conn->keepalives_interval);
free(conn->keepalives_count);
free(conn->sslmode);
free(conn->sslcert);
free(conn->sslkey);
libpq should expose GSS-related parameters even when not implemented. We realized years ago that it's better for libpq to accept all connection parameters syntactically, even if some are ignored or restricted due to lack of the feature in a particular build. However, that lesson from the SSL support was for some reason never applied to the GSSAPI support. This is causing various buildfarm members to have problems with a test case added by commit 6136e94dc, and it's just a bad idea from a user-experience standpoint anyway, so fix it. While at it, fix some places where parameter-related infrastructure was added with the aid of a dartboard, or perhaps with the aid of the anti-pattern "add new stuff at the end". It should be safe to rearrange the contents of struct pg_conn even in released branches, since that's private to libpq (and we'd have to move some fields in some builds to fix this, anyway). Back-patch to all supported branches. Discussion: https://postgr.es/m/11297.1576868677@sss.pgh.pa.us
2019-12-20 21:34:07 +01:00
if (conn->sslpassword)
Use explicit_bzero() when clearing sslpassword in libpq Since 74a308c, any security-sensitive information gets cleared from memory this way. This was forgotten in 4dc6355. Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/935443BA-D42E-4CE0-B181-1AD79E6DD45A@yesql.se
2020-05-21 08:49:20 +02:00
{
explicit_bzero(conn->sslpassword, strlen(conn->sslpassword));
libpq should expose GSS-related parameters even when not implemented. We realized years ago that it's better for libpq to accept all connection parameters syntactically, even if some are ignored or restricted due to lack of the feature in a particular build. However, that lesson from the SSL support was for some reason never applied to the GSSAPI support. This is causing various buildfarm members to have problems with a test case added by commit 6136e94dc, and it's just a bad idea from a user-experience standpoint anyway, so fix it. While at it, fix some places where parameter-related infrastructure was added with the aid of a dartboard, or perhaps with the aid of the anti-pattern "add new stuff at the end". It should be safe to rearrange the contents of struct pg_conn even in released branches, since that's private to libpq (and we'd have to move some fields in some builds to fix this, anyway). Back-patch to all supported branches. Discussion: https://postgr.es/m/11297.1576868677@sss.pgh.pa.us
2019-12-20 21:34:07 +01:00
free(conn->sslpassword);
Use explicit_bzero() when clearing sslpassword in libpq Since 74a308c, any security-sensitive information gets cleared from memory this way. This was forgotten in 4dc6355. Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/935443BA-D42E-4CE0-B181-1AD79E6DD45A@yesql.se
2020-05-21 08:49:20 +02:00
}
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->sslrootcert);
free(conn->sslcrl);
free(conn->sslcrldir);
free(conn->sslcompression);
free(conn->sslsni);
free(conn->requirepeer);
free(conn->ssl_min_protocol_version);
free(conn->ssl_max_protocol_version);
free(conn->gssencmode);
free(conn->krbsrvname);
free(conn->gsslib);
free(conn->connip);
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
/* Note that conn->Pfdebug is not ours to close or free */
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(conn->write_err_msg);
free(conn->inBuffer);
free(conn->outBuffer);
free(conn->rowBuf);
free(conn->target_session_attrs);
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
termPQExpBuffer(&conn->errorMessage);
termPQExpBuffer(&conn->workBuffer);
Fix up closePGconn() so that PQreset() will work on GSSAPI/SSPI connections; the patch for those features put its cleanup code into freePGconn() which is really the wrong place. Remove redundant code from freePGconn() and add comments in hopes of preventing similar mistakes in future. Noticed while trying (futilely) to reproduce bug #3902.
2008-01-29 03:06:30 +01:00
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
free(conn);
}
/*
In libpq, don't look up all the hostnames at once. Historically, we looked up the target hostname in connectDBStart, so that PQconnectPoll did not need to do DNS name resolution. The patches that added multiple-target-host support to libpq preserved this division of labor; but it's really nonsensical now, because it means that if any one of the target hosts fails to resolve in DNS, the connection fails. That negates the no-single-point-of-failure goal of the feature. Additionally, DNS lookups aren't exactly cheap, but the code did them all even if the first connection attempt succeeds. Hence, rearrange so that PQconnectPoll does the lookups, and only looks up a hostname when it's time to try that host. This does mean that PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid that, you should be using hostaddr, as the documentation has always specified. It seems fairly unlikely that any applications would really care whether the lookup occurs inside PQconnectStart or PQconnectPoll. In addition to calling out that fact explicitly, do some other minor wordsmithing in the docs around the multiple-target-host feature. Since this seems like a bug in the multiple-target-host feature, backpatch to v10 where that was introduced. In the back branches, avoid moving any existing fields of struct pg_conn, just in case any third-party code is looking into that struct. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
2018-08-23 22:39:19 +02:00
* release_conn_addrinfo
* - Free any addrinfo list in the PGconn.
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
*/
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
static void
In libpq, don't look up all the hostnames at once. Historically, we looked up the target hostname in connectDBStart, so that PQconnectPoll did not need to do DNS name resolution. The patches that added multiple-target-host support to libpq preserved this division of labor; but it's really nonsensical now, because it means that if any one of the target hosts fails to resolve in DNS, the connection fails. That negates the no-single-point-of-failure goal of the feature. Additionally, DNS lookups aren't exactly cheap, but the code did them all even if the first connection attempt succeeds. Hence, rearrange so that PQconnectPoll does the lookups, and only looks up a hostname when it's time to try that host. This does mean that PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid that, you should be using hostaddr, as the documentation has always specified. It seems fairly unlikely that any applications would really care whether the lookup occurs inside PQconnectStart or PQconnectPoll. In addition to calling out that fact explicitly, do some other minor wordsmithing in the docs around the multiple-target-host feature. Since this seems like a bug in the multiple-target-host feature, backpatch to v10 where that was introduced. In the back branches, avoid moving any existing fields of struct pg_conn, just in case any third-party code is looking into that struct. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
2018-08-23 22:39:19 +02:00
release_conn_addrinfo(PGconn *conn)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
In libpq, don't look up all the hostnames at once. Historically, we looked up the target hostname in connectDBStart, so that PQconnectPoll did not need to do DNS name resolution. The patches that added multiple-target-host support to libpq preserved this division of labor; but it's really nonsensical now, because it means that if any one of the target hosts fails to resolve in DNS, the connection fails. That negates the no-single-point-of-failure goal of the feature. Additionally, DNS lookups aren't exactly cheap, but the code did them all even if the first connection attempt succeeds. Hence, rearrange so that PQconnectPoll does the lookups, and only looks up a hostname when it's time to try that host. This does mean that PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid that, you should be using hostaddr, as the documentation has always specified. It seems fairly unlikely that any applications would really care whether the lookup occurs inside PQconnectStart or PQconnectPoll. In addition to calling out that fact explicitly, do some other minor wordsmithing in the docs around the multiple-target-host feature. Since this seems like a bug in the multiple-target-host feature, backpatch to v10 where that was introduced. In the back branches, avoid moving any existing fields of struct pg_conn, just in case any third-party code is looking into that struct. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
2018-08-23 22:39:19 +02:00
if (conn->addrlist)
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
{
In libpq, don't look up all the hostnames at once. Historically, we looked up the target hostname in connectDBStart, so that PQconnectPoll did not need to do DNS name resolution. The patches that added multiple-target-host support to libpq preserved this division of labor; but it's really nonsensical now, because it means that if any one of the target hosts fails to resolve in DNS, the connection fails. That negates the no-single-point-of-failure goal of the feature. Additionally, DNS lookups aren't exactly cheap, but the code did them all even if the first connection attempt succeeds. Hence, rearrange so that PQconnectPoll does the lookups, and only looks up a hostname when it's time to try that host. This does mean that PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid that, you should be using hostaddr, as the documentation has always specified. It seems fairly unlikely that any applications would really care whether the lookup occurs inside PQconnectStart or PQconnectPoll. In addition to calling out that fact explicitly, do some other minor wordsmithing in the docs around the multiple-target-host feature. Since this seems like a bug in the multiple-target-host feature, backpatch to v10 where that was introduced. In the back branches, avoid moving any existing fields of struct pg_conn, just in case any third-party code is looking into that struct. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
2018-08-23 22:39:19 +02:00
pg_freeaddrinfo_all(conn->addrlist_family, conn->addrlist);
conn->addrlist = NULL;
conn->addr_cur = NULL; /* for safety */
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
}
}
/*
* sendTerminateConn
* - Send a terminate message to backend.
*/
static void
sendTerminateConn(PGconn *conn)
{
Repair libpq to follow protocol by not sending Terminate messages before the startup exchange is complete. Also make sure that packets defined as single bytes aren't sent with a trailing '\0'.
2001-07-06 19:58:53 +02:00
/*
* Note that the protocol doesn't allow us to send Terminate messages
Use MD5 for wire protocol encryption for >= 7.2 client/server. Allow pg_shadow to be MD5 encrypted. Add ENCRYPTED/UNENCRYPTED option to CREATE/ALTER user. Add password_encryption postgresql.conf option. Update wire protocol version to 2.1.
2001-08-15 20:42:16 +02:00
* during the startup phase.
*/
libpq: use pgsocket for socket values, for portability Previously, 'int' was used for socket values in libpq, but socket values are unsigned on Windows. This is a style correction. Initial patch and previous PGINVALID_SOCKET initial patch by Joel Jacobson, modified by me Report from PVS-Studio
2014-04-17 01:46:51 +02:00
if (conn->sock != PGINVALID_SOCKET && conn->status == CONNECTION_OK)
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
{
/*
The attached patch implements some changes that were discussed a couple weeks ago on the hackers and interfaces lists: 1. When the backend sends a NOTICE message and closes the connection (typically, because it was told to by the postmaster after another backend coredumped), libpq will now print the notice and close the connection cleanly. Formerly, the frontend app would usually terminate ungracefully due to a SIGPIPE. (I am not sure if 6.3.2 behaved that way, but the current cvs sources do...) 2. libpq's various printouts to stderr are now fed through a single "notice processor" routine, which can be overridden by the application to direct notices someplace else. This should ease porting libpq to Windows. I also noticed and fixed a problem in PQprint: when sending output to a pager subprocess, it would disable SIGPIPE in case the pager terminates early (this is good) --- but afterwards it reset SIGPIPE to SIG_DFL, rather than restoring the application's prior setting (bad). regards, tom lane
1998-08-09 04:59:33 +02:00
* Try to send "close connection" message to backend. Ignore any
Second round of FE/BE protocol changes. Frontend->backend messages now have length counts, and COPY IN data is packetized into messages.
2003-04-19 02:02:30 +02:00
* error.
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
*/
Remove server and libpq support for old FE/BE protocol version 2. Protocol version 3 was introduced in PostgreSQL 7.4. There shouldn't be many clients or servers left out there without version 3 support. But as a courtesy, I kept just enough of the old protocol support that we can still send the "unsupported protocol version" error in v2 format, so that old clients can display the message properly. Likewise, libpq still understands v2 ErrorResponse messages when establishing a connection. The impetus to do this now is that I'm working on a patch to COPY FROM, to always prefetch some data. We cannot do that safely with the old protocol, because it requires parsing the input one byte at a time to detect the end-of-copy marker. Reviewed-by: Tom Lane, Alvaro Herrera, John Naylor Discussion: https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cca3b%40iki.fi
2021-03-04 09:45:55 +01:00
pqPutMsgStart('X', conn);
Second round of FE/BE protocol changes. Frontend->backend messages now have length counts, and COPY IN data is packetized into messages.
2003-04-19 02:02:30 +02:00
pqPutMsgEnd(conn);
Various Coverity-spotted fixes A number of issues were identified by the Coverity scanner and are addressed in this patch. None of these appear to be security issues and many are mostly cosmetic changes. Short comments for each of the changes follows. Correct the semi-colon placement in be-secure.c regarding SSL retries. Remove a useless comparison-to-NULL in proc.c (value is dereferenced prior to this check and therefore can't be NULL). Add checking of chmod() return values to initdb. Fix a couple minor memory leaks in initdb. Fix memory leak in pg_ctl- involves free'ing the config file contents. Use an int to capture fgetc() return instead of an enum in pg_dump. Fix minor memory leaks in pg_dump. (note minor change to convertOperatorReference()'s API) Check fclose()/remove() return codes in psql. Check fstat(), find_my_exec() return codes in psql. Various ECPG memory leak fixes. Check find_my_exec() return in ECPG. Explicitly ignore pqFlush return in libpq error-path. Change PQfnumber() to avoid doing an strdup() when no changes required. Remove a few useless check-against-NULL's (value deref'd beforehand). Check rmtree(), malloc() results in pg_regress. Also check get_alternative_expectfile() return in pg_regress.
2014-03-02 04:14:14 +01:00
(void) pqFlush(conn);
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
}
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
}
/*
* closePGconn
* - properly close a connection to the backend
*
* This should reset or release all transient state, but NOT the connection
* parameters. On exit, the PGconn should be in condition to start a fresh
* connection with the same parameters (see PQreset()).
*/
static void
closePGconn(PGconn *conn)
{
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/*
* If possible, send Terminate message to close the connection politely.
*/
libpq: Add target_session_attrs parameter. Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to specify multiple IPs in a connection string, but that's not good enough for the case where you have a read-write master and a bunch of read-only standbys and want to connect to whichever server is the master at the current time. This commit allows that, by making it possible to specify target_session_attrs=read-write as a connection parameter. There was extensive discussion of the best name for the connection parameter and its values as well as the best way to distinguish master and standbys. For now, adopt the same solution as JDBC: if the user wants a read-write connection, issue 'show transaction_read_only' and rejection the connection if the result is 'on'. In the future, we could add additional values of this new target_session_attrs parameter that issue different queries; or we might have some way of distinguishing the server type without resorting to an SQL query; but right now, we have this, and that's (hopefully) a good start. Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I changed Mithun's patch to skip all remaining IPs for a host if we reject a connection based on this new parameter, rewrote the documentation, and did some other cosmetic cleanup. Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
sendTerminateConn(conn);
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
Remove Ops parameter from STATRELID cache lookup, for Tom Lane and optimizer.
2000-01-24 03:12:58 +01:00
/*
Fix up closePGconn() so that PQreset() will work on GSSAPI/SSPI connections; the patch for those features put its cleanup code into freePGconn() which is really the wrong place. Remove redundant code from freePGconn() and add comments in hopes of preventing similar mistakes in future. Noticed while trying (futilely) to reproduce bug #3902.
2008-01-29 03:06:30 +01:00
* Must reset the blocking status so a possible reconnect will work.
*
* Don't call PQsetnonblocking() because it will fail if it's unable to
* flush the connection.
Remove Ops parameter from STATRELID cache lookup, for Tom Lane and optimizer.
2000-01-24 03:12:58 +01:00
*/
Change TRUE/FALSE to true/false The lower case spellings are C and C++ standard and are used in most parts of the PostgreSQL sources. The upper case spellings are only used in some files/modules. So standardize on the standard spellings. The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so those are left as is when using those APIs. In code comments, we use the lower-case spelling for the C concepts and keep the upper-case spelling for the SQL concepts. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-08-16 06:22:32 +02:00
conn->nonblocking = false;
Remove Ops parameter from STATRELID cache lookup, for Tom Lane and optimizer.
2000-01-24 03:12:58 +01:00
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
/*
* Close the connection, reset all transient state, flush I/O buffers.
Rearrange libpq's error reporting to avoid duplicated error text. Since commit ffa2e4670, libpq accumulates text in conn->errorMessage across a whole query cycle. In some situations, we may report more than one error event within a cycle: the easiest case to reach is where we report a FATAL error message from the server, and then a bit later we detect loss of connection. Since, historically, each error PGresult bears the entire content of conn->errorMessage, this results in duplication of the FATAL message in any output that concatenates the contents of the PGresults. Accumulation in errorMessage still seems like a good idea, especially in view of the number of places that did ad-hoc error concatenation before ffa2e4670. So to fix this, let's track how much of conn->errorMessage has been read out into error PGresults, and only include new text in later PGresults. The tricky part of that is to be sure that we never discard an error PGresult once made (else we'd risk dropping some text, a problem much worse than duplication). While libpq formerly did that in some code paths, a little bit of rearrangement lets us postpone making an error PGresult at all until we are about to return it. A side benefit of that postponement is that it now becomes practical to return a dummy static PGresult in cases where we hit out-of-memory while trying to manufacture an error PGresult. This eliminates the admittedly-very-rare case where we'd return NULL from PQgetResult, indicating successful query completion, even though what actually happened was an OOM failure. Discussion: https://postgr.es/m/ab4288f8-be5c-57fb-2400-e3e857f53e46@enterprisedb.com
2022-02-18 21:35:15 +01:00
* Note that this includes clearing conn's error state; we're no longer
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
* interested in any failures associated with the old connection, and we
* want a clean slate for any new connection attempt.
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
*/
Fix unwanted flushing of libpq's input buffer when socket EOF is seen. In commit 210eb9b743c0645d I centralized libpq's logic for closing down the backend communication socket, and made the new pqDropConnection routine always reset the I/O buffers to empty. Many of the call sites previously had not had such code, and while that amounted to an oversight in some cases, there was one place where it was intentional and necessary *not* to flush the input buffer: pqReadData should never cause that to happen, since we probably still want to process whatever data we read. This is the true cause of the problem Robert was attempting to fix in c3e7c24a1d60dc6a, namely that libpq no longer reported the backend's final ERROR message before reporting "server closed the connection unexpectedly". But that only accidentally fixed it, by invoking parseInput before the input buffer got flushed; and very likely there are timing scenarios where we'd still lose the message before processing it. To fix, pass a flag to pqDropConnection to tell it whether to flush the input buffer or not. On review I think flushing is actually correct for every other call site. Back-patch to 9.3 where the problem was introduced. In HEAD, also improve the comments added by c3e7c24a1d60dc6a.
2015-11-12 19:03:52 +01:00
pqDropConnection(conn, true);
Fixes: When you connect to a database with PQsetdb, as with psql, depending on how your uninitialized variables are set, you can get a failure with a "There is no connection to the backend" message. The fix is to move a call to PQexec() from inside connectDB() to PQsetdb() after connectDB() returns to PQsetdb(). That way a connection doesn't have to be already established in order to establish it! From: bryanh@giraffe.netgate.net (Bryan Henderson)
1996-08-19 15:25:40 +02:00
conn->status = CONNECTION_BAD; /* Well, not really _bad_ - just absent */
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
conn->asyncStatus = PGASYNC_IDLE;
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
conn->xactStatus = PQTRANS_IDLE;
Implement pipeline mode in libpq Pipeline mode in libpq lets an application avoid the Sync messages in the FE/BE protocol that are implicit in the old libpq API after each query. The application can then insert Sync at its leisure with a new libpq function PQpipelineSync. This can lead to substantial reductions in query latency. Co-authored-by: Craig Ringer <craig.ringer@enterprisedb.com> Co-authored-by: Matthieu Garrigues <matthieu.garrigues@gmail.com> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Aya Iwata <iwata.aya@jp.fujitsu.com> Reviewed-by: Daniel Vérité <daniel@manitou-mail.org> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Kirk Jamison <k.jamison@fujitsu.com> Reviewed-by: Michael Paquier <michael.paquier@gmail.com> Reviewed-by: Nikhil Sontakke <nikhils@2ndquadrant.com> Reviewed-by: Vaishnavi Prabakaran <VaishnaviP@fast.au.fujitsu.com> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Discussion: https://postgr.es/m/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com Discussion: https://postgr.es/m/CAJkzx4T5E-2cQe3dtv2R78dYFvz+in8PY7A8MArvLhs_pg75gg@mail.gmail.com
2021-03-15 22:13:42 +01:00
conn->pipelineStatus = PQ_PIPELINE_OFF;
Add a "row processor" API to libpq for better handling of large results. Traditionally libpq has collected an entire query result before passing it back to the application. That provides a simple and transactional API, but it's pretty inefficient for large result sets. This patch allows the application to process each row on-the-fly instead of accumulating the rows into the PGresult. Error recovery becomes a bit more complex, but often that tradeoff is well worth making. Kyotaro Horiguchi, reviewed by Marko Kreen and Tom Lane
2012-04-05 00:27:56 +02:00
pqClearAsyncResult(conn); /* deallocate result */
Rearrange libpq's error reporting to avoid duplicated error text. Since commit ffa2e4670, libpq accumulates text in conn->errorMessage across a whole query cycle. In some situations, we may report more than one error event within a cycle: the easiest case to reach is where we report a FATAL error message from the server, and then a bit later we detect loss of connection. Since, historically, each error PGresult bears the entire content of conn->errorMessage, this results in duplication of the FATAL message in any output that concatenates the contents of the PGresults. Accumulation in errorMessage still seems like a good idea, especially in view of the number of places that did ad-hoc error concatenation before ffa2e4670. So to fix this, let's track how much of conn->errorMessage has been read out into error PGresults, and only include new text in later PGresults. The tricky part of that is to be sure that we never discard an error PGresult once made (else we'd risk dropping some text, a problem much worse than duplication). While libpq formerly did that in some code paths, a little bit of rearrangement lets us postpone making an error PGresult at all until we are about to return it. A side benefit of that postponement is that it now becomes practical to return a dummy static PGresult in cases where we hit out-of-memory while trying to manufacture an error PGresult. This eliminates the admittedly-very-rare case where we'd return NULL from PQgetResult, indicating successful query completion, even though what actually happened was an OOM failure. Discussion: https://postgr.es/m/ab4288f8-be5c-57fb-2400-e3e857f53e46@enterprisedb.com
2022-02-18 21:35:15 +01:00
pqClearConnErrorState(conn);
In libpq, don't look up all the hostnames at once. Historically, we looked up the target hostname in connectDBStart, so that PQconnectPoll did not need to do DNS name resolution. The patches that added multiple-target-host support to libpq preserved this division of labor; but it's really nonsensical now, because it means that if any one of the target hosts fails to resolve in DNS, the connection fails. That negates the no-single-point-of-failure goal of the feature. Additionally, DNS lookups aren't exactly cheap, but the code did them all even if the first connection attempt succeeds. Hence, rearrange so that PQconnectPoll does the lookups, and only looks up a hostname when it's time to try that host. This does mean that PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid that, you should be using hostaddr, as the documentation has always specified. It seems fairly unlikely that any applications would really care whether the lookup occurs inside PQconnectStart or PQconnectPoll. In addition to calling out that fact explicitly, do some other minor wordsmithing in the docs around the multiple-target-host feature. Since this seems like a bug in the multiple-target-host feature, backpatch to v10 where that was introduced. In the back branches, avoid moving any existing fields of struct pg_conn, just in case any third-party code is looking into that struct. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
2018-08-23 22:39:19 +02:00
release_conn_addrinfo(conn);
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
/* Reset all state obtained from server, too */
pqDropServerData(conn);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
libpq was not consistently checking for memory allocation failures. This patch adds missing checks to the call sites of malloc(), strdup(), PQmakeEmptyPGresult(), pqResultAlloc(), and pqResultStrdup(), and updates the documentation. Per original report from Volkan Yazici about PQmakeEmptyPGresult() not checking for malloc() failure.
2005-06-12 02:00:21 +02:00
* PQfinish: properly close a connection to the backend. Also frees
* the PGconn data structure so it shouldn't be re-used after this.
*/
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
void
PQfinish(PGconn *conn)
{
The attached patch implements some changes that were discussed a couple weeks ago on the hackers and interfaces lists: 1. When the backend sends a NOTICE message and closes the connection (typically, because it was told to by the postmaster after another backend coredumped), libpq will now print the notice and close the connection cleanly. Formerly, the frontend app would usually terminate ungracefully due to a SIGPIPE. (I am not sure if 6.3.2 behaved that way, but the current cvs sources do...) 2. libpq's various printouts to stderr are now fed through a single "notice processor" routine, which can be overridden by the application to direct notices someplace else. This should ease porting libpq to Windows. I also noticed and fixed a problem in PQprint: when sending output to a pager subprocess, it would disable SIGPIPE in case the pager terminates early (this is good) --- but afterwards it reset SIGPIPE to SIG_DFL, rather than restoring the application's prior setting (bad). regards, tom lane
1998-08-09 04:59:33 +02:00
if (conn)
fixes for several potential null pointer dereferences submitted by: Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
1996-07-12 06:53:59 +02:00
{
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
closePGconn(conn);
fixes for several potential null pointer dereferences submitted by: Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
1996-07-12 06:53:59 +02:00
freePGconn(conn);
}
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
libpq was not consistently checking for memory allocation failures. This patch adds missing checks to the call sites of malloc(), strdup(), PQmakeEmptyPGresult(), pqResultAlloc(), and pqResultStrdup(), and updates the documentation. Per original report from Volkan Yazici about PQmakeEmptyPGresult() not checking for malloc() failure.
2005-06-12 02:00:21 +02:00
/*
* PQreset: resets the connection to the backend by closing the
* existing connection and creating a new one.
*/
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
void
PQreset(PGconn *conn)
{
The attached patch implements some changes that were discussed a couple weeks ago on the hackers and interfaces lists: 1. When the backend sends a NOTICE message and closes the connection (typically, because it was told to by the postmaster after another backend coredumped), libpq will now print the notice and close the connection cleanly. Formerly, the frontend app would usually terminate ungracefully due to a SIGPIPE. (I am not sure if 6.3.2 behaved that way, but the current cvs sources do...) 2. libpq's various printouts to stderr are now fed through a single "notice processor" routine, which can be overridden by the application to direct notices someplace else. This should ease porting libpq to Windows. I also noticed and fixed a problem in PQprint: when sending output to a pager subprocess, it would disable SIGPIPE in case the pager terminates early (this is good) --- but afterwards it reset SIGPIPE to SIG_DFL, rather than restoring the application's prior setting (bad). regards, tom lane
1998-08-09 04:59:33 +02:00
if (conn)
fixes for several potential null pointer dereferences submitted by: Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
1996-07-12 06:53:59 +02:00
{
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
closePGconn(conn);
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
Add an "events" system to libpq, whereby applications can get callbacks that enable them to manage private data associated with PGconns and PGresults. Andrew Chernow and Merlin Moncure
2008-09-17 06:31:08 +02:00
if (connectDBStart(conn) && connectDBComplete(conn))
{
/*
Don't let libpq PGEVT_CONNRESET callbacks break a PGconn. As currently implemented, failure of a PGEVT_CONNRESET callback forces the PGconn into the CONNECTION_BAD state (without closing the socket, which is inconsistent with other failure paths), and prevents later callbacks from being called. This seems highly questionable, and indeed is questioned by comments in the source. Instead, let's just ignore the result value of PGEVT_CONNRESET calls. Like the preceding commit, this converts event callbacks into "pure observers" that cannot affect libpq's processing logic. Discussion: https://postgr.es/m/3185105.1644960083@sss.pgh.pa.us
2022-02-18 17:43:04 +01:00
* Notify event procs of successful reset.
Add an "events" system to libpq, whereby applications can get callbacks that enable them to manage private data associated with PGconns and PGresults. Andrew Chernow and Merlin Moncure
2008-09-17 06:31:08 +02:00
*/
int i;
for (i = 0; i < conn->nEvents; i++)
{
PGEventConnReset evt;
evt.conn = conn;
Don't let libpq PGEVT_CONNRESET callbacks break a PGconn. As currently implemented, failure of a PGEVT_CONNRESET callback forces the PGconn into the CONNECTION_BAD state (without closing the socket, which is inconsistent with other failure paths), and prevents later callbacks from being called. This seems highly questionable, and indeed is questioned by comments in the source. Instead, let's just ignore the result value of PGEVT_CONNRESET calls. Like the preceding commit, this converts event callbacks into "pure observers" that cannot affect libpq's processing logic. Discussion: https://postgr.es/m/3185105.1644960083@sss.pgh.pa.us
2022-02-18 17:43:04 +01:00
(void) conn->events[i].proc(PGEVT_CONNRESET, &evt,
conn->events[i].passThrough);
Add an "events" system to libpq, whereby applications can get callbacks that enable them to manage private data associated with PGconns and PGresults. Andrew Chernow and Merlin Moncure
2008-09-17 06:31:08 +02:00
}
}
fixes for several potential null pointer dereferences submitted by: Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
1996-07-12 06:53:59 +02:00
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
}
libpq was not consistently checking for memory allocation failures. This patch adds missing checks to the call sites of malloc(), strdup(), PQmakeEmptyPGresult(), pqResultAlloc(), and pqResultStrdup(), and updates the documentation. Per original report from Volkan Yazici about PQmakeEmptyPGresult() not checking for malloc() failure.
2005-06-12 02:00:21 +02:00
/*
* PQresetStart:
* resets the connection to the backend
* closes the existing connection and makes a new one
* Returns 1 on success, 0 on failure.
*/
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
int
PQresetStart(PGconn *conn)
{
if (conn)
{
closePGconn(conn);
return connectDBStart(conn);
}
Clean up some problems in new asynchronous-connection logic in libpq --- mostly, poor response to error conditions. You now actually get to see the postmaster's 'The Data Base System is starting up' message, which you didn't before. I suspect the SSL code is still broken though.
2000-01-14 06:33:15 +01:00
return 0;
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
}
libpq was not consistently checking for memory allocation failures. This patch adds missing checks to the call sites of malloc(), strdup(), PQmakeEmptyPGresult(), pqResultAlloc(), and pqResultStrdup(), and updates the documentation. Per original report from Volkan Yazici about PQmakeEmptyPGresult() not checking for malloc() failure.
2005-06-12 02:00:21 +02:00
/*
* PQresetPoll:
* resets the connection to the backend
* closes the existing connection and makes a new one
*/
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
PostgresPollingStatusType
PQresetPoll(PGconn *conn)
{
if (conn)
Add an "events" system to libpq, whereby applications can get callbacks that enable them to manage private data associated with PGconns and PGresults. Andrew Chernow and Merlin Moncure
2008-09-17 06:31:08 +02:00
{
PostgresPollingStatusType status = PQconnectPoll(conn);
if (status == PGRES_POLLING_OK)
{
/*
Don't let libpq PGEVT_CONNRESET callbacks break a PGconn. As currently implemented, failure of a PGEVT_CONNRESET callback forces the PGconn into the CONNECTION_BAD state (without closing the socket, which is inconsistent with other failure paths), and prevents later callbacks from being called. This seems highly questionable, and indeed is questioned by comments in the source. Instead, let's just ignore the result value of PGEVT_CONNRESET calls. Like the preceding commit, this converts event callbacks into "pure observers" that cannot affect libpq's processing logic. Discussion: https://postgr.es/m/3185105.1644960083@sss.pgh.pa.us
2022-02-18 17:43:04 +01:00
* Notify event procs of successful reset.
Add an "events" system to libpq, whereby applications can get callbacks that enable them to manage private data associated with PGconns and PGresults. Andrew Chernow and Merlin Moncure
2008-09-17 06:31:08 +02:00
*/
int i;
for (i = 0; i < conn->nEvents; i++)
{
PGEventConnReset evt;
evt.conn = conn;
Don't let libpq PGEVT_CONNRESET callbacks break a PGconn. As currently implemented, failure of a PGEVT_CONNRESET callback forces the PGconn into the CONNECTION_BAD state (without closing the socket, which is inconsistent with other failure paths), and prevents later callbacks from being called. This seems highly questionable, and indeed is questioned by comments in the source. Instead, let's just ignore the result value of PGEVT_CONNRESET calls. Like the preceding commit, this converts event callbacks into "pure observers" that cannot affect libpq's processing logic. Discussion: https://postgr.es/m/3185105.1644960083@sss.pgh.pa.us
2022-02-18 17:43:04 +01:00
(void) conn->events[i].proc(PGEVT_CONNRESET, &evt,
conn->events[i].passThrough);
Add an "events" system to libpq, whereby applications can get callbacks that enable them to manage private data associated with PGconns and PGresults. Andrew Chernow and Merlin Moncure
2008-09-17 06:31:08 +02:00
}
}
return status;
}
This patch (against the current CVS sources) adds to libpq the functions PQconnectStart PQconnectPoll PQresetStart PQresetPoll PQsetenvStart PQsetenvPoll PQsetenvAbort and brings into the published interface PQsetenv. The first four are asynchronous analogues of PQconnectdb and PQreset - they allow an application to connect to the DB without blocking on remote I/O. The PQsetenv functions perform an environment negotiation with the server. Internal to libpq, pqReadReady and pqWriteReady have been made available across the library (they were previously static functions inside fe-misc.c). A lot of internal rearrangement has been necessary to support these changes. The API documentation has been updated also. Caveats: o The Windows code does not default to using non-blocking sockets, since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to do that. o The SSL code still blocks. Ewan Mellor.
1999-11-30 04:08:19 +01:00
return PGRES_POLLING_FAILED;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
/*
Fix typo Etsuro Fujita
2016-04-05 11:05:01 +02:00
* PQgetCancel: get a PGcancel structure corresponding to a connection.
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
*
* A copy is needed to be able to cancel a running query from a different
* thread. If the same structure is used all structure members would have
* to be individually locked (if the entire structure was locked, it would
Fix typo in comment.
2006-05-19 16:26:58 +02:00
* be impossible to cancel a synchronous query because the structure would
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
* have to stay locked for the duration of the query).
*/
PGcancel *
PQgetCancel(PGconn *conn)
{
PGcancel *cancel;
if (!conn)
return NULL;
libpq: use pgsocket for socket values, for portability Previously, 'int' was used for socket values in libpq, but socket values are unsigned on Windows. This is a style correction. Initial patch and previous PGINVALID_SOCKET initial patch by Joel Jacobson, modified by me Report from PVS-Studio
2014-04-17 01:46:51 +02:00
if (conn->sock == PGINVALID_SOCKET)
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
return NULL;
cancel = malloc(sizeof(PGcancel));
if (cancel == NULL)
return NULL;
memcpy(&cancel->raddr, &conn->raddr, sizeof(SockAddr));
cancel->be_pid = conn->be_pid;
cancel->be_key = conn->be_key;
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
/* We use -1 to indicate an unset connection option */
cancel->pgtcp_user_timeout = -1;
cancel->keepalives = -1;
cancel->keepalives_idle = -1;
cancel->keepalives_interval = -1;
cancel->keepalives_count = -1;
if (conn->pgtcp_user_timeout != NULL)
{
if (!parse_int_param(conn->pgtcp_user_timeout,
&cancel->pgtcp_user_timeout,
conn, "tcp_user_timeout"))
goto fail;
}
if (conn->keepalives != NULL)
{
if (!parse_int_param(conn->keepalives,
&cancel->keepalives,
conn, "keepalives"))
goto fail;
}
if (conn->keepalives_idle != NULL)
{
if (!parse_int_param(conn->keepalives_idle,
&cancel->keepalives_idle,
conn, "keepalives_idle"))
goto fail;
}
if (conn->keepalives_interval != NULL)
{
if (!parse_int_param(conn->keepalives_interval,
&cancel->keepalives_interval,
conn, "keepalives_interval"))
goto fail;
}
if (conn->keepalives_count != NULL)
{
if (!parse_int_param(conn->keepalives_count,
&cancel->keepalives_count,
conn, "keepalives_count"))
goto fail;
}
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
return cancel;
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
fail:
free(cancel);
return NULL;
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
}
/* PQfreeCancel: free a cancel structure */
void
PQfreeCancel(PGcancel *cancel)
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(cancel);
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
}
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
/*
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
* Sets an integer socket option on a TCP socket, if the provided value is
* not negative. Returns false if setsockopt fails for some reason.
*
* CAUTION: This needs to be signal safe, since it's used by PQcancel.
*/
#if defined(TCP_USER_TIMEOUT) || !defined(WIN32)
static bool
optional_setsockopt(int fd, int protoid, int optid, int value)
{
if (value < 0)
return true;
if (setsockopt(fd, protoid, optid, (char *) &value, sizeof(value)) < 0)
return false;
return true;
}
#endif
/*
* PQcancel: request query cancel
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
*
Change TRUE/FALSE to true/false The lower case spellings are C and C++ standard and are used in most parts of the PostgreSQL sources. The upper case spellings are only used in some files/modules. So standardize on the standard spellings. The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so those are left as is when using those APIs. In code comments, we use the lower-case spelling for the C concepts and keep the upper-case spelling for the SQL concepts. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-08-16 06:22:32 +02:00
* The return value is true if the cancel request was successfully
* dispatched, false if not (in which case an error message is available).
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
* Note: successful dispatch is no guarantee that there will be any effect at
* the backend. The application must read the operation result as usual.
*
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
* On failure, an error message is stored in *errbuf, which must be of size
* errbufsize (recommended size is 256 bytes). *errbuf is not changed on
* success return.
*
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
* CAUTION: we want this routine to be safely callable from a signal handler
* (for example, an application might want to call it in a SIGINT handler).
* This means we cannot use any C library routine that might be non-reentrant.
* malloc/free are often non-reentrant, and anything that might call them is
* just as dangerous. We avoid sprintf here for that reason. Building up
* error messages with strcpy/strcat is tedious but should be quite safe.
Ensure that 'errno' is saved and restored by all signal handlers that might change it. Experimentation shows that the signal handler call mechanism does not save/restore errno for you, at least not on Linux or HPUX, so this is definitely a real risk.
2000-12-18 18:33:42 +01:00
* We also save/restore errno in case the signal handler support doesn't.
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
*/
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
int
PQcancel(PGcancel *cancel, char *errbuf, int errbufsize)
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
{
> Ok, where's a "system dependent hack" :) > It seems that win9x doesn't have the "netmsg.dll" so it defaults to "normal" > FormatMessage. > I wonder if one could load wsock32.dll or winsock.dll on those systems > instead of netmsg.dll. > > Mikhail, could you please test this code on your nt4 system? > Could someone else test this code on a win98/95 system? > > It works on win2k over here. It works on win2k here too but not on win98/95 or winNT. Anyway, attached is the patch which uses Magnus's my_sock_strerror function (renamed to winsock_strerror). The only difference is that I put the code to load and unload netmsg.dll in the libpqdll.c (is this OK Magnus?). Mikhail Terekhov
2001-08-21 22:39:54 +02:00
int save_errno = SOCK_ERRNO;
check socket creation errors against PGINVALID_SOCKET Previously, in some places, socket creation errors were checked for negative values, which is not true for Windows because sockets are unsigned. This masked socket creation errors on Windows. Backpatch through 9.0. 8.4 doesn't have the infrastructure to fix this.
2014-04-16 16:45:48 +02:00
pgsocket tmpsock = PGINVALID_SOCKET;
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
int maxlen;
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
struct
{
uint32 packetlen;
CancelRequestPacket cp;
} crp;
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
if (!cancel)
{
strlcpy(errbuf, "PQcancel() -- no cancel object supplied", errbufsize);
/* strlcpy probably doesn't change errno, but be paranoid */
SOCK_ERRNO_SET(save_errno);
return false;
}
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
/*
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
* We need to open a temporary connection to the postmaster. Do this with
* only kernel calls.
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
*/
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
if ((tmpsock = socket(cancel->raddr.addr.ss_family, SOCK_STREAM, 0)) == PGINVALID_SOCKET)
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
{
StrNCpy -> strlcpy (not complete)
2007-02-10 15:58:55 +01:00
strlcpy(errbuf, "PQcancel() -- socket() failed: ", errbufsize);
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
goto cancel_errReturn;
}
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
/*
* Since this connection will only be used to send a single packet of
* data, we don't need NODELAY. We also don't set the socket to
* nonblocking mode, because the API definition of PQcancel requires the
* cancel to be sent in a blocking way.
*
* We do set socket options related to keepalives and other TCP timeouts.
* This ensures that this function does not block indefinitely when
* reasonable keepalive and timeout settings have been provided.
*/
Remove IS_AF_UNIX macro The AF_UNIX macro was being used unprotected by HAVE_UNIX_SOCKETS, apparently since 2008. So the redirection through IS_AF_UNIX() is apparently no longer necessary. (More generally, all supported platforms are now HAVE_UNIX_SOCKETS, but even if there were a new platform in the future, it seems plausible that it would define the AF_UNIX symbol even without kernel support.) So remove the IS_AF_UNIX() macro and make the code a bit more consistent. Discussion: https://www.postgresql.org/message-id/flat/f2d26815-9832-e333-d52d-72fbc0ade896%40enterprisedb.com
2022-02-15 10:03:52 +01:00
if (cancel->raddr.addr.ss_family != AF_UNIX &&
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
cancel->keepalives != 0)
{
#ifndef WIN32
if (!optional_setsockopt(tmpsock, SOL_SOCKET, SO_KEEPALIVE, 1))
{
strlcpy(errbuf, "PQcancel() -- setsockopt(SO_KEEPALIVE) failed: ", errbufsize);
goto cancel_errReturn;
}
#ifdef PG_TCP_KEEPALIVE_IDLE
if (!optional_setsockopt(tmpsock, IPPROTO_TCP, PG_TCP_KEEPALIVE_IDLE,
cancel->keepalives_idle))
{
strlcpy(errbuf, "PQcancel() -- setsockopt(" PG_TCP_KEEPALIVE_IDLE_STR ") failed: ", errbufsize);
goto cancel_errReturn;
}
#endif
#ifdef TCP_KEEPINTVL
if (!optional_setsockopt(tmpsock, IPPROTO_TCP, TCP_KEEPINTVL,
cancel->keepalives_interval))
{
strlcpy(errbuf, "PQcancel() -- setsockopt(TCP_KEEPINTVL) failed: ", errbufsize);
goto cancel_errReturn;
}
#endif
#ifdef TCP_KEEPCNT
if (!optional_setsockopt(tmpsock, IPPROTO_TCP, TCP_KEEPCNT,
cancel->keepalives_count))
{
strlcpy(errbuf, "PQcancel() -- setsockopt(TCP_KEEPCNT) failed: ", errbufsize);
goto cancel_errReturn;
}
#endif
#else /* WIN32 */
#ifdef SIO_KEEPALIVE_VALS
if (!setKeepalivesWin32(tmpsock,
cancel->keepalives_idle,
cancel->keepalives_interval))
{
strlcpy(errbuf, "PQcancel() -- WSAIoctl(SIO_KEEPALIVE_VALS) failed: ", errbufsize);
goto cancel_errReturn;
}
#endif /* SIO_KEEPALIVE_VALS */
#endif /* WIN32 */
/* TCP_USER_TIMEOUT works the same way on Unix and Windows */
#ifdef TCP_USER_TIMEOUT
if (!optional_setsockopt(tmpsock, IPPROTO_TCP, TCP_USER_TIMEOUT,
cancel->pgtcp_user_timeout))
{
strlcpy(errbuf, "PQcancel() -- setsockopt(TCP_USER_TIMEOUT) failed: ", errbufsize);
goto cancel_errReturn;
}
#endif
}
Fix for EINTR returns from Win9X socket operations: In summary, if a software writer implements timer events or other events which generate a signal with a timing fast enough to occur while libpq is inside connect(), then connect returns -EINTR. The code following the connect call does not handle this and generates an error message. The sum result is that the pg_connect() fails. If the timer or other event is right on the window of the connect() completion time, the pg_connect() may appear to work sporadically. If the event is too slow, pg_connect() will appear to always work and if the event is too fast, pg_connect() will always fail. David Ford
2002-04-16 01:34:17 +02:00
retry3:
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
if (connect(tmpsock, (struct sockaddr *) &cancel->raddr.addr,
cancel->raddr.salen) < 0)
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
{
Fix for EINTR returns from Win9X socket operations: In summary, if a software writer implements timer events or other events which generate a signal with a timing fast enough to occur while libpq is inside connect(), then connect returns -EINTR. The code following the connect call does not handle this and generates an error message. The sum result is that the pg_connect() fails. If the timer or other event is right on the window of the connect() completion time, the pg_connect() may appear to work sporadically. If the event is too slow, pg_connect() will appear to always work and if the event is too fast, pg_connect() will always fail. David Ford
2002-04-16 01:34:17 +02:00
if (SOCK_ERRNO == EINTR)
/* Interrupted system call - we'll just try again */
goto retry3;
StrNCpy -> strlcpy (not complete)
2007-02-10 15:58:55 +01:00
strlcpy(errbuf, "PQcancel() -- connect() failed: ", errbufsize);
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
goto cancel_errReturn;
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
/* Create and send the cancel request packet. */
Replace most usages of ntoh[ls] and hton[sl] with pg_bswap.h. All postgres internal usages are replaced, it's just libpq example usages that haven't been converted. External users of libpq can't generally rely on including postgres internal headers. Note that this includes replacing open-coded byte swapping of 64bit integers (using two 32 bit swaps) with a single 64bit swap. Where it looked applicable, I have removed netinet/in.h and arpa/inet.h usage, which previously provided the relevant functionality. It's perfectly possible that I missed other reasons for including those, the buildfarm will tell. Author: Andres Freund Discussion: https://postgr.es/m/20170927172019.gheidqy6xvlxb325@alap3.anarazel.de
2017-10-02 00:36:14 +02:00
crp.packetlen = pg_hton32((uint32) sizeof(crp));
crp.cp.cancelRequestCode = (MsgType) pg_hton32(CANCEL_REQUEST_CODE);
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
crp.cp.backendPID = pg_hton32(cancel->be_pid);
crp.cp.cancelAuthCode = pg_hton32(cancel->be_key);
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
Fix for EINTR returns from Win9X socket operations: In summary, if a software writer implements timer events or other events which generate a signal with a timing fast enough to occur while libpq is inside connect(), then connect returns -EINTR. The code following the connect call does not handle this and generates an error message. The sum result is that the pg_connect() fails. If the timer or other event is right on the window of the connect() completion time, the pg_connect() may appear to work sporadically. If the event is too slow, pg_connect() will appear to always work and if the event is too fast, pg_connect() will always fail. David Ford
2002-04-16 01:34:17 +02:00
retry4:
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
if (send(tmpsock, (char *) &crp, sizeof(crp), 0) != (int) sizeof(crp))
{
Fix for EINTR returns from Win9X socket operations: In summary, if a software writer implements timer events or other events which generate a signal with a timing fast enough to occur while libpq is inside connect(), then connect returns -EINTR. The code following the connect call does not handle this and generates an error message. The sum result is that the pg_connect() fails. If the timer or other event is right on the window of the connect() completion time, the pg_connect() may appear to work sporadically. If the event is too slow, pg_connect() will appear to always work and if the event is too fast, pg_connect() will always fail. David Ford
2002-04-16 01:34:17 +02:00
if (SOCK_ERRNO == EINTR)
/* Interrupted system call - we'll just try again */
goto retry4;
StrNCpy -> strlcpy (not complete)
2007-02-10 15:58:55 +01:00
strlcpy(errbuf, "PQcancel() -- send() failed: ", errbufsize);
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
goto cancel_errReturn;
}
Do not return from PQrequestCancel until postmaster has finished processing the request; this ensures that the request won't be taken to cancel a subsequently-issued query. Race condition originally noted by Oliver Jowett in the context of JDBC, but libpq has it too.
2003-10-02 21:52:44 +02:00
/*
* Wait for the postmaster to close the connection, which indicates that
* it's processed the request. Without this delay, we might issue another
* command only to find that our cancel zaps that command instead of the
* one we thought we were canceling. Note we don't actually expect this
* read to obtain any data, we are just waiting for EOF to be signaled.
*/
retry5:
if (recv(tmpsock, (char *) &crp, 1, 0) < 0)
{
if (SOCK_ERRNO == EINTR)
/* Interrupted system call - we'll just try again */
goto retry5;
/* we ignore other error conditions */
}
/* All done */
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
closesocket(tmpsock);
Clean up code in libpq that obtains user's home directory: make a single subroutine that can hide platform dependencies. The WIN32 path is still a stub, but I await a fix from one of the win32 hackers. Also clean up unnecessary #ifdef WIN32 ugliness in a couple of places.
2005-01-05 00:18:25 +01:00
SOCK_ERRNO_SET(save_errno);
Change TRUE/FALSE to true/false The lower case spellings are C and C++ standard and are used in most parts of the PostgreSQL sources. The upper case spellings are only used in some files/modules. So standardize on the standard spellings. The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so those are left as is when using those APIs. In code comments, we use the lower-case spelling for the C concepts and keep the upper-case spelling for the SQL concepts. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-08-16 06:22:32 +02:00
return true;
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
cancel_errReturn:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
/*
* Make sure we don't overflow the error buffer. Leave space for the \n at
* the end, and for the terminating zero.
*/
maxlen = errbufsize - strlen(errbuf) - 2;
if (maxlen >= 0)
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
{
Avoid calling strerror[_r] in PQcancel(). PQcancel() is supposed to be safe to call from a signal handler, and indeed psql uses it that way. All of the library functions it uses are specified to be async-signal-safe by POSIX ... except for strerror. Neither plain strerror nor strerror_r are considered safe. When this code was written, back in the dark ages, we probably figured "oh, strerror will just index into a constant array of strings" ... but in any locale except C, that's unlikely to be true. Probably the reason we've not heard complaints is that (a) this error-handling code is unlikely to be reached in normal use, and (b) in many scenarios, localized error strings would already have been loaded, after which maybe it's safe to call strerror here. Still, this is clearly unacceptable. The best we can do without relying on strerror is to print the decimal value of errno, so make it do that instead. (This is probably not much loss of user-friendliness, given that it is hard to get a failure here.) Back-patch to all supported branches. Discussion: https://postgr.es/m/2937814.1641960929@sss.pgh.pa.us
2022-01-17 18:52:44 +01:00
/*
* We can't invoke strerror here, since it's not signal-safe. Settle
* for printing the decimal value of errno. Even that has to be done
* the hard way.
*/
int val = SOCK_ERRNO;
char buf[32];
char *bufp;
bufp = buf + sizeof(buf) - 1;
*bufp = '\0';
do
{
*(--bufp) = (val % 10) + '0';
val /= 10;
} while (val > 0);
bufp -= 6;
memcpy(bufp, "error ", 6);
strncat(errbuf, bufp, maxlen);
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
strcat(errbuf, "\n");
}
check socket creation errors against PGINVALID_SOCKET Previously, in some places, socket creation errors were checked for negative values, which is not true for Windows because sockets are unsigned. This masked socket creation errors on Windows. Backpatch through 9.0. 8.4 doesn't have the infrastructure to fix this.
2014-04-16 16:45:48 +02:00
if (tmpsock != PGINVALID_SOCKET)
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
closesocket(tmpsock);
Clean up code in libpq that obtains user's home directory: make a single subroutine that can hide platform dependencies. The WIN32 path is still a stub, but I await a fix from one of the win32 hackers. Also clean up unnecessary #ifdef WIN32 ugliness in a couple of places.
2005-01-05 00:18:25 +01:00
SOCK_ERRNO_SET(save_errno);
Change TRUE/FALSE to true/false The lower case spellings are C and C++ standard and are used in most parts of the PostgreSQL sources. The upper case spellings are only used in some files/modules. So standardize on the standard spellings. The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so those are left as is when using those APIs. In code comments, we use the lower-case spelling for the C concepts and keep the upper-case spelling for the SQL concepts. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-08-16 06:22:32 +02:00
return false;
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
}
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
/*
* PQrequestCancel: old, not thread-safe function for requesting query cancel
*
Change TRUE/FALSE to true/false The lower case spellings are C and C++ standard and are used in most parts of the PostgreSQL sources. The upper case spellings are only used in some files/modules. So standardize on the standard spellings. The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so those are left as is when using those APIs. In code comments, we use the lower-case spelling for the C concepts and keep the upper-case spelling for the SQL concepts. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-08-16 06:22:32 +02:00
* Returns true if able to send the cancel request, false if not.
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
*
* On failure, the error message is saved in conn->errorMessage; this means
* that this can't be used when there might be other active operations on
* the connection object.
*
* NOTE: error messages will be cut off at the current size of the
* error message buffer, since we dare not try to expand conn->errorMessage!
*/
int
PQrequestCancel(PGconn *conn)
{
int r;
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
PGcancel *cancel;
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
/* Check we have an open connection */
if (!conn)
Change TRUE/FALSE to true/false The lower case spellings are C and C++ standard and are used in most parts of the PostgreSQL sources. The upper case spellings are only used in some files/modules. So standardize on the standard spellings. The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so those are left as is when using those APIs. In code comments, we use the lower-case spelling for the C concepts and keep the upper-case spelling for the SQL concepts. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-08-16 06:22:32 +02:00
return false;
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
libpq: use pgsocket for socket values, for portability Previously, 'int' was used for socket values in libpq, but socket values are unsigned on Windows. This is a style correction. Initial patch and previous PGINVALID_SOCKET initial patch by Joel Jacobson, modified by me Report from PVS-Studio
2014-04-17 01:46:51 +02:00
if (conn->sock == PGINVALID_SOCKET)
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
{
StrNCpy -> strlcpy (not complete)
2007-02-10 15:58:55 +01:00
strlcpy(conn->errorMessage.data,
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
"PQrequestCancel() -- connection is not open\n",
conn->errorMessage.maxlen);
conn->errorMessage.len = strlen(conn->errorMessage.data);
Reset conn->errorReported when PQrequestCancel sets errorMessage. Oversight in commit 618c16707. This is mainly neatnik-ism, since if PQrequestCancel is used per its API contract, we should perform pqClearConnErrorState before reaching any place that would consult errorReported. But still, it seems like a bad idea to potentially leave errorReported pointing past errorMessage.len.
2022-02-20 21:02:41 +01:00
conn->errorReported = 0;
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
Change TRUE/FALSE to true/false The lower case spellings are C and C++ standard and are used in most parts of the PostgreSQL sources. The upper case spellings are only used in some files/modules. So standardize on the standard spellings. The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so those are left as is when using those APIs. In code comments, we use the lower-case spelling for the C concepts and keep the upper-case spelling for the SQL concepts. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-08-16 06:22:32 +02:00
return false;
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
}
Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings. If connectivity to the server has been lost or become flaky, the user might well try to send a query cancel. It's highly annoying if PQcancel hangs up in such a case, but that's exactly what's likely to happen. To ameliorate this problem, apply the PGconn's tcp_user_timeout and keepalives settings to the TCP connection used to send the cancel. This should be safe on Unix machines, since POSIX specifies that setsockopt() is async-signal-safe. We are guessing that WSAIoctl(SIO_KEEPALIVE_VALS) is similarly safe on Windows. (Note that at least in psql and our other frontend programs, there's no safety issue involved anyway, since we run PQcancel in its own thread rather than in a signal handler.) Most of the value here comes from the expectation that tcp_user_timeout will be applied as a connection timeout. That appears to happen on Linux, even though its tcp(7) man page claims differently. The keepalive options probably won't help much, but as long as we can apply them for not much code, we might as well. Jelte Fennema, reviewed by Fujii Masao and myself Discussion: https://postgr.es/m/AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com
2022-01-18 20:02:43 +01:00
cancel = PQgetCancel(conn);
if (cancel)
{
r = PQcancel(cancel, conn->errorMessage.data,
conn->errorMessage.maxlen);
PQfreeCancel(cancel);
}
else
{
strlcpy(conn->errorMessage.data, "out of memory",
conn->errorMessage.maxlen);
r = false;
}
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
if (!r)
Reset conn->errorReported when PQrequestCancel sets errorMessage. Oversight in commit 618c16707. This is mainly neatnik-ism, since if PQrequestCancel is used per its API contract, we should perform pqClearConnErrorState before reaching any place that would consult errorReported. But still, it seems like a bad idea to potentially leave errorReported pointing past errorMessage.len.
2022-02-20 21:02:41 +01:00
{
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
conn->errorMessage.len = strlen(conn->errorMessage.data);
Reset conn->errorReported when PQrequestCancel sets errorMessage. Oversight in commit 618c16707. This is mainly neatnik-ism, since if PQrequestCancel is used per its API contract, we should perform pqClearConnErrorState before reaching any place that would consult errorReported. But still, it seems like a bad idea to potentially leave errorReported pointing past errorMessage.len.
2022-02-20 21:02:41 +01:00
conn->errorReported = 0;
}
Invent a new, more thread-safe version of PQrequestCancel, called PQcancel. Use this new function in psql. Implement query cancellation in psql for Windows. Code by Magnus Hagander, documentation and minor editorialization by Tom Lane.
2004-10-31 01:11:27 +02:00
return r;
}
From: Tom Lane <tgl@sss.pgh.pa.us> Making PQrequestCancel safe to call in a signal handler turned out to be much easier than I feared. So here are the diffs. Some notes: * I modified the postmaster's packet "iodone" callback interface to allow the callback routine to return a continue-or-drop-connection return code; this was necessary to allow the connection to be closed after receiving a Cancel, rather than proceeding to launch a new backend... Being a neatnik, I also made the iodone proc have a typechecked parameter list. * I deleted all code I could find that had to do with OOB. * I made some edits to ensure that all signals mentioned in the code are referred to symbolically not by numbers ("SIGUSR2" not "2"). I think Bruce may have already done at least some of the same edits; I hope that merging these patches is not too painful.
1998-07-09 05:29:11 +02:00
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*
Second round of FE/BE protocol changes. Frontend->backend messages now have length counts, and COPY IN data is packetized into messages.
2003-04-19 02:02:30 +02:00
* pqPacketSend() -- convenience routine to send a message to server.
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
*
* pack_type: the single-byte message type code. (Pass zero for startup
* packets, which have no message type code.)
*
* buf, buf_len: contents of message. The given length includes only what
* is in buf; the message type and message length fields are added here.
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*
* RETURNS: STATUS_ERROR if the write fails, STATUS_OK otherwise.
* SIDE_EFFECTS: may block.
libpq can now talk to either 3.0 or 2.0 protocol servers. It first tries protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
2003-06-08 19:43:00 +02:00
*/
From: Dan McGuirk <mcguirk@indirect.com> Subject: [HACKERS] password authentication This patch adds support for plaintext password authentication. To use it, you add a line like host all 0.0.0.0 0.0.0.0 password pg_pwd.conf to your pg_hba.conf, where 'pg_pwd.conf' is the name of a file containing the usernames and password hashes in the format of the first two fields of a Unix /etc/passwd file. (Of course, you can use a specific database name or IP instead.) Then, to connect with a password through libpq, you use the PQconnectdb() function, specifying the "password=" tag in the connect string and also adding the tag "authtype=password". I also added a command-line switch '-u' to psql that tells it to prompt for a username and password and use password authentication.
1997-03-12 22:23:16 +01:00
int
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
pqPacketSend(PGconn *conn, char pack_type,
const void *buf, size_t buf_len)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Second round of FE/BE protocol changes. Frontend->backend messages now have length counts, and COPY IN data is packetized into messages.
2003-04-19 02:02:30 +02:00
/* Start the message. */
Remove server and libpq support for old FE/BE protocol version 2. Protocol version 3 was introduced in PostgreSQL 7.4. There shouldn't be many clients or servers left out there without version 3 support. But as a courtesy, I kept just enough of the old protocol support that we can still send the "unsupported protocol version" error in v2 format, so that old clients can display the message properly. Likewise, libpq still understands v2 ErrorResponse messages when establishing a connection. The impetus to do this now is that I'm working on a patch to COPY FROM, to always prefetch some data. We cannot do that safely with the old protocol, because it requires parsing the input one byte at a time to detect the end-of-copy marker. Reviewed-by: Tom Lane, Alvaro Herrera, John Naylor Discussion: https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cca3b%40iki.fi
2021-03-04 09:45:55 +01:00
if (pqPutMsgStart(pack_type, conn))
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
return STATUS_ERROR;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
/* Send the message body. */
if (pqPutnchar(buf, buf_len, conn))
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
return STATUS_ERROR;
From: todd brandys <brandys@eng3.hep.uiuc.edu> An extension to the code to allow for a pg_password authentication database that is *seperate* from the system password file
1997-12-04 01:28:15 +01:00
Second round of FE/BE protocol changes. Frontend->backend messages now have length counts, and COPY IN data is packetized into messages.
2003-04-19 02:02:30 +02:00
/* Finish the message. */
if (pqPutMsgEnd(conn))
return STATUS_ERROR;
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
/* Flush to ensure backend gets it. */
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
if (pqFlush(conn))
return STATUS_ERROR;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
return STATUS_OK;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
#ifdef USE_LDAP
#define LDAP_URL "ldap://"
#define LDAP_DEF_PORT 389
#define PGLDAP_TIMEOUT 2
#define ld_is_sp_tab(x) ((x) == ' ' || (x) == '\t')
#define ld_is_nl_cr(x) ((x) == '\r' || (x) == '\n')
/*
* ldapServiceLookup
*
* Search the LDAP URL passed as first argument, treat the result as a
* string of connection options that are parsed and added to the array of
* options passed as second argument.
*
* LDAP URLs must conform to RFC 1959 without escape sequences.
* ldap://host:port/dn?attributes?scope?filter?extensions
*
* Returns
* 0 if the lookup was successful,
* 1 if the connection to the LDAP server could be established but
* the search was unsuccessful,
* 2 if a connection could not be established, and
* 3 if a fatal error occurred.
*
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
* An error message is appended to *errorMessage for return codes 1 and 3.
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
*/
static int
ldapServiceLookup(const char *purl, PQconninfoOption *options,
PQExpBuffer errorMessage)
{
int port = LDAP_DEF_PORT,
scope,
rc,
size,
state,
oldstate,
i;
Fix unused-variable warning on Windows. Introduced in 585bca39: msgid is not used in the Windows code path. Also adjust comments a tad (mostly to keep pgindent from messing it up). David Rowley
2014-04-17 22:12:24 +02:00
#ifndef WIN32
int msgid;
#endif
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
bool found_keyword;
char *url,
*hostname,
*portstr,
*endptr,
*dn,
*scopestr,
*filter,
*result,
*p,
*p1 = NULL,
*optname = NULL,
*optval = NULL;
char *attrs[2] = {NULL, NULL};
LDAP *ld = NULL;
LDAPMessage *res,
*entry;
struct berval **values;
LDAP_TIMEVAL time = {PGLDAP_TIMEOUT, 0};
if ((url = strdup(purl)) == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage, libpq_gettext("out of memory\n"));
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
return 3;
}
/*
* Parse URL components, check for correctness. Basically, url has '\0'
* placed at component boundaries and variables are pointed at each
* component.
*/
Fix some uses of str[n]casecmp that should be pg_str[n]casecmp, per Magnus.
2006-09-15 23:34:23 +02:00
if (pg_strncasecmp(url, LDAP_URL, strlen(LDAP_URL)) != 0)
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Message style improvements
2006-10-06 19:14:01 +02:00
libpq_gettext("invalid LDAP URL \"%s\": scheme must be ldap://\n"), purl);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
free(url);
return 3;
}
/* hostname */
hostname = url + strlen(LDAP_URL);
if (*hostname == '/') /* no hostname? */
Properly print the IP number and "localhost" for failed localhost connections when the server is down, on Win32.
2010-12-18 17:25:41 +01:00
hostname = DefaultHost; /* the default */
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
/* dn, "distinguished name" */
p = strchr(url + strlen(LDAP_URL), '/');
if (p == NULL || *(p + 1) == '\0' || *(p + 1) == '?')
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Message style improvements
2006-10-06 19:14:01 +02:00
libpq_gettext("invalid LDAP URL \"%s\": missing distinguished name\n"),
purl);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
free(url);
return 3;
}
*p = '\0'; /* terminate hostname */
dn = p + 1;
/* attribute */
if ((p = strchr(dn, '?')) == NULL || *(p + 1) == '\0' || *(p + 1) == '?')
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Message style improvements
2006-10-06 19:14:01 +02:00
libpq_gettext("invalid LDAP URL \"%s\": must have exactly one attribute\n"),
purl);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
free(url);
return 3;
}
*p = '\0';
attrs[0] = p + 1;
/* scope */
if ((p = strchr(attrs[0], '?')) == NULL || *(p + 1) == '\0' || *(p + 1) == '?')
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
libpq_gettext("invalid LDAP URL \"%s\": must have search scope (base/one/sub)\n"),
purl);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
free(url);
return 3;
}
*p = '\0';
scopestr = p + 1;
/* filter */
if ((p = strchr(scopestr, '?')) == NULL || *(p + 1) == '\0' || *(p + 1) == '?')
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
libpq_gettext("invalid LDAP URL \"%s\": no filter\n"),
purl);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
free(url);
return 3;
}
*p = '\0';
filter = p + 1;
if ((p = strchr(filter, '?')) != NULL)
*p = '\0';
Locate the file pg_service.conf in the directory configured as --syconfdir (i.e., /usr/local/pgsql/etc by default).
2000-10-17 19:43:13 +02:00
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
/* port number? */
if ((p1 = strchr(hostname, ':')) != NULL)
{
long lport;
*p1 = '\0';
portstr = p1 + 1;
errno = 0;
lport = strtol(portstr, &endptr, 10);
if (*portstr == '\0' || *endptr != '\0' || errno || lport < 0 || lport > 65535)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Message style improvements
2006-10-06 19:14:01 +02:00
libpq_gettext("invalid LDAP URL \"%s\": invalid port number\n"),
purl);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
free(url);
return 3;
}
port = (int) lport;
}
/* Allow only one attribute */
if (strchr(attrs[0], ',') != NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Message style improvements
2006-10-06 19:14:01 +02:00
libpq_gettext("invalid LDAP URL \"%s\": must have exactly one attribute\n"),
purl);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
free(url);
return 3;
}
/* set scope */
Fix some uses of str[n]casecmp that should be pg_str[n]casecmp, per Magnus.
2006-09-15 23:34:23 +02:00
if (pg_strcasecmp(scopestr, "base") == 0)
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
scope = LDAP_SCOPE_BASE;
Fix some uses of str[n]casecmp that should be pg_str[n]casecmp, per Magnus.
2006-09-15 23:34:23 +02:00
else if (pg_strcasecmp(scopestr, "one") == 0)
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
scope = LDAP_SCOPE_ONELEVEL;
Fix some uses of str[n]casecmp that should be pg_str[n]casecmp, per Magnus.
2006-09-15 23:34:23 +02:00
else if (pg_strcasecmp(scopestr, "sub") == 0)
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
scope = LDAP_SCOPE_SUBTREE;
else
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
libpq_gettext("invalid LDAP URL \"%s\": must have search scope (base/one/sub)\n"),
purl);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
free(url);
return 3;
}
/* initialize LDAP structure */
if ((ld = ldap_init(hostname, port)) == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("could not create LDAP structure\n"));
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
free(url);
return 3;
}
/*
Fix timeout in LDAP lookup of libpq connection parameters Bind attempts to an LDAP server should time out after two seconds, allowing additional lines in the service control file to be parsed (which provide a fall back to a secondary LDAP server or default options). The existing code failed to enforce that timeout during TCP connect, resulting in a hang far longer than two seconds if the LDAP server does not respond. Laurenz Albe
2014-04-16 17:18:02 +02:00
* Perform an explicit anonymous bind.
Fix unused-variable warning on Windows. Introduced in 585bca39: msgid is not used in the Windows code path. Also adjust comments a tad (mostly to keep pgindent from messing it up). David Rowley
2014-04-17 22:12:24 +02:00
*
* LDAP does not require that an anonymous bind is performed explicitly,
Fix timeout in LDAP lookup of libpq connection parameters Bind attempts to an LDAP server should time out after two seconds, allowing additional lines in the service control file to be parsed (which provide a fall back to a secondary LDAP server or default options). The existing code failed to enforce that timeout during TCP connect, resulting in a hang far longer than two seconds if the LDAP server does not respond. Laurenz Albe
2014-04-16 17:18:02 +02:00
* but we want to distinguish between the case where LDAP bind does not
* succeed within PGLDAP_TIMEOUT seconds (return 2 to continue parsing the
* service control file) and the case where querying the LDAP server fails
* (return 1 to end parsing).
Fix unused-variable warning on Windows. Introduced in 585bca39: msgid is not used in the Windows code path. Also adjust comments a tad (mostly to keep pgindent from messing it up). David Rowley
2014-04-17 22:12:24 +02:00
*
Fix timeout in LDAP lookup of libpq connection parameters Bind attempts to an LDAP server should time out after two seconds, allowing additional lines in the service control file to be parsed (which provide a fall back to a secondary LDAP server or default options). The existing code failed to enforce that timeout during TCP connect, resulting in a hang far longer than two seconds if the LDAP server does not respond. Laurenz Albe
2014-04-16 17:18:02 +02:00
* Unfortunately there is no way of setting a timeout that works for both
* Windows and OpenLDAP.
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
*/
Fix timeout in LDAP lookup of libpq connection parameters Bind attempts to an LDAP server should time out after two seconds, allowing additional lines in the service control file to be parsed (which provide a fall back to a secondary LDAP server or default options). The existing code failed to enforce that timeout during TCP connect, resulting in a hang far longer than two seconds if the LDAP server does not respond. Laurenz Albe
2014-04-16 17:18:02 +02:00
#ifdef WIN32
/* the nonstandard ldap_connect function performs an anonymous bind */
if (ldap_connect(ld, &time) != LDAP_SUCCESS)
{
/* error or timeout in ldap_connect */
free(url);
ldap_unbind(ld);
return 2;
}
Fix unused-variable warning on Windows. Introduced in 585bca39: msgid is not used in the Windows code path. Also adjust comments a tad (mostly to keep pgindent from messing it up). David Rowley
2014-04-17 22:12:24 +02:00
#else /* !WIN32 */
Fix timeout in LDAP lookup of libpq connection parameters Bind attempts to an LDAP server should time out after two seconds, allowing additional lines in the service control file to be parsed (which provide a fall back to a secondary LDAP server or default options). The existing code failed to enforce that timeout during TCP connect, resulting in a hang far longer than two seconds if the LDAP server does not respond. Laurenz Albe
2014-04-16 17:18:02 +02:00
/* in OpenLDAP, use the LDAP_OPT_NETWORK_TIMEOUT option */
if (ldap_set_option(ld, LDAP_OPT_NETWORK_TIMEOUT, &time) != LDAP_SUCCESS)
{
free(url);
ldap_unbind(ld);
return 3;
}
/* anonymous bind */
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
if ((msgid = ldap_simple_bind(ld, NULL, NULL)) == -1)
{
Fix timeout in LDAP lookup of libpq connection parameters Bind attempts to an LDAP server should time out after two seconds, allowing additional lines in the service control file to be parsed (which provide a fall back to a secondary LDAP server or default options). The existing code failed to enforce that timeout during TCP connect, resulting in a hang far longer than two seconds if the LDAP server does not respond. Laurenz Albe
2014-04-16 17:18:02 +02:00
/* error or network timeout */
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
free(url);
ldap_unbind(ld);
return 2;
}
/* wait some time for the connection to succeed */
res = NULL;
if ((rc = ldap_result(ld, msgid, LDAP_MSG_ALL, &time, &res)) == -1 ||
res == NULL)
{
Fix timeout in LDAP lookup of libpq connection parameters Bind attempts to an LDAP server should time out after two seconds, allowing additional lines in the service control file to be parsed (which provide a fall back to a secondary LDAP server or default options). The existing code failed to enforce that timeout during TCP connect, resulting in a hang far longer than two seconds if the LDAP server does not respond. Laurenz Albe
2014-04-16 17:18:02 +02:00
/* error or timeout */
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
if (res != NULL)
ldap_msgfree(res);
free(url);
ldap_unbind(ld);
return 2;
}
ldap_msgfree(res);
Fix timeout in LDAP lookup of libpq connection parameters Bind attempts to an LDAP server should time out after two seconds, allowing additional lines in the service control file to be parsed (which provide a fall back to a secondary LDAP server or default options). The existing code failed to enforce that timeout during TCP connect, resulting in a hang far longer than two seconds if the LDAP server does not respond. Laurenz Albe
2014-04-16 17:18:02 +02:00
/* reset timeout */
time.tv_sec = -1;
if (ldap_set_option(ld, LDAP_OPT_NETWORK_TIMEOUT, &time) != LDAP_SUCCESS)
{
free(url);
ldap_unbind(ld);
return 3;
}
#endif /* WIN32 */
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
/* search */
res = NULL;
if ((rc = ldap_search_st(ld, dn, scope, filter, attrs, 0, &time, &res))
!= LDAP_SUCCESS)
{
if (res != NULL)
ldap_msgfree(res);
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
libpq_gettext("lookup on LDAP server failed: %s\n"),
ldap_err2string(rc));
ldap_unbind(ld);
free(url);
return 1;
}
/* complain if there was not exactly one result */
if ((rc = ldap_count_entries(ld, res)) != 1)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
rc ? libpq_gettext("more than one entry found on LDAP lookup\n")
: libpq_gettext("no entry found on LDAP lookup\n"));
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
ldap_msgfree(res);
ldap_unbind(ld);
free(url);
return 1;
}
/* get entry */
if ((entry = ldap_first_entry(ld, res)) == NULL)
{
/* should never happen */
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("no entry found on LDAP lookup\n"));
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
ldap_msgfree(res);
ldap_unbind(ld);
free(url);
return 1;
}
/* get values */
if ((values = ldap_get_values_len(ld, entry, attrs[0])) == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("attribute has no values on LDAP lookup\n"));
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
ldap_msgfree(res);
ldap_unbind(ld);
free(url);
return 1;
}
ldap_msgfree(res);
free(url);
if (values[0] == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("attribute has no values on LDAP lookup\n"));
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
ldap_value_free_len(values);
ldap_unbind(ld);
return 1;
}
Fix write-past-buffer-end in ldapServiceLookup(). The code to assemble ldap_get_values_len's output into a single string wrote the terminating null one byte past where it should. Fix that, and make some other cosmetic adjustments to make the code a trifle more readable and more in line with usual Postgres coding style. Also, free the "result" string when done with it, to avoid a permanent memory leak. Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
2011-05-12 17:56:38 +02:00
/* concatenate values into a single string with newline terminators */
size = 1; /* for the trailing null */
for (i = 0; values[i] != NULL; i++)
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
size += values[i]->bv_len + 1;
Fix write-past-buffer-end in ldapServiceLookup(). The code to assemble ldap_get_values_len's output into a single string wrote the terminating null one byte past where it should. Fix that, and make some other cosmetic adjustments to make the code a trifle more readable and more in line with usual Postgres coding style. Also, free the "result" string when done with it, to avoid a permanent memory leak. Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
2011-05-12 17:56:38 +02:00
if ((result = malloc(size)) == NULL)
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
ldap_value_free_len(values);
ldap_unbind(ld);
return 3;
}
Fix write-past-buffer-end in ldapServiceLookup(). The code to assemble ldap_get_values_len's output into a single string wrote the terminating null one byte past where it should. Fix that, and make some other cosmetic adjustments to make the code a trifle more readable and more in line with usual Postgres coding style. Also, free the "result" string when done with it, to avoid a permanent memory leak. Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
2011-05-12 17:56:38 +02:00
p = result;
for (i = 0; values[i] != NULL; i++)
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
{
Fix write-past-buffer-end in ldapServiceLookup(). The code to assemble ldap_get_values_len's output into a single string wrote the terminating null one byte past where it should. Fix that, and make some other cosmetic adjustments to make the code a trifle more readable and more in line with usual Postgres coding style. Also, free the "result" string when done with it, to avoid a permanent memory leak. Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
2011-05-12 17:56:38 +02:00
memcpy(p, values[i]->bv_val, values[i]->bv_len);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
p += values[i]->bv_len;
*(p++) = '\n';
}
Fix write-past-buffer-end in ldapServiceLookup(). The code to assemble ldap_get_values_len's output into a single string wrote the terminating null one byte past where it should. Fix that, and make some other cosmetic adjustments to make the code a trifle more readable and more in line with usual Postgres coding style. Also, free the "result" string when done with it, to avoid a permanent memory leak. Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
2011-05-12 17:56:38 +02:00
*p = '\0';
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
ldap_value_free_len(values);
ldap_unbind(ld);
/* parse result string */
oldstate = state = 0;
for (p = result; *p != '\0'; ++p)
{
switch (state)
{
case 0: /* between entries */
if (!ld_is_sp_tab(*p) && !ld_is_nl_cr(*p))
{
optname = p;
state = 1;
}
break;
case 1: /* in option name */
if (ld_is_sp_tab(*p))
{
*p = '\0';
state = 2;
}
else if (ld_is_nl_cr(*p))
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
libpq_gettext("missing \"=\" after \"%s\" in connection info string\n"),
optname);
Fix write-past-buffer-end in ldapServiceLookup(). The code to assemble ldap_get_values_len's output into a single string wrote the terminating null one byte past where it should. Fix that, and make some other cosmetic adjustments to make the code a trifle more readable and more in line with usual Postgres coding style. Also, free the "result" string when done with it, to avoid a permanent memory leak. Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
2011-05-12 17:56:38 +02:00
free(result);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
return 3;
}
else if (*p == '=')
{
*p = '\0';
state = 3;
}
break;
case 2: /* after option name */
if (*p == '=')
{
state = 3;
}
else if (!ld_is_sp_tab(*p))
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
libpq_gettext("missing \"=\" after \"%s\" in connection info string\n"),
optname);
Fix write-past-buffer-end in ldapServiceLookup(). The code to assemble ldap_get_values_len's output into a single string wrote the terminating null one byte past where it should. Fix that, and make some other cosmetic adjustments to make the code a trifle more readable and more in line with usual Postgres coding style. Also, free the "result" string when done with it, to avoid a permanent memory leak. Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
2011-05-12 17:56:38 +02:00
free(result);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
return 3;
}
break;
case 3: /* before option value */
if (*p == '\'')
{
optval = p + 1;
p1 = p + 1;
state = 5;
}
else if (ld_is_nl_cr(*p))
{
optval = optname + strlen(optname); /* empty */
state = 0;
}
else if (!ld_is_sp_tab(*p))
{
optval = p;
state = 4;
}
break;
case 4: /* in unquoted option value */
if (ld_is_sp_tab(*p) || ld_is_nl_cr(*p))
{
*p = '\0';
state = 0;
}
break;
case 5: /* in quoted option value */
if (*p == '\'')
{
*p1 = '\0';
state = 0;
}
else if (*p == '\\')
state = 6;
else
*(p1++) = *p;
break;
case 6: /* in quoted option value after escape */
*(p1++) = *p;
state = 5;
break;
}
if (state == 0 && oldstate != 0)
{
found_keyword = false;
for (i = 0; options[i].keyword; i++)
{
if (strcmp(options[i].keyword, optname) == 0)
{
if (options[i].val == NULL)
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
{
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
options[i].val = strdup(optval);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!options[i].val)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
free(result);
return 3;
}
}
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
found_keyword = true;
break;
}
}
if (!found_keyword)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
libpq_gettext("invalid connection option \"%s\"\n"),
optname);
Fix write-past-buffer-end in ldapServiceLookup(). The code to assemble ldap_get_values_len's output into a single string wrote the terminating null one byte past where it should. Fix that, and make some other cosmetic adjustments to make the code a trifle more readable and more in line with usual Postgres coding style. Also, free the "result" string when done with it, to avoid a permanent memory leak. Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
2011-05-12 17:56:38 +02:00
free(result);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
return 1;
}
optname = NULL;
optval = NULL;
}
oldstate = state;
}
Fix write-past-buffer-end in ldapServiceLookup(). The code to assemble ldap_get_values_len's output into a single string wrote the terminating null one byte past where it should. Fix that, and make some other cosmetic adjustments to make the code a trifle more readable and more in line with usual Postgres coding style. Also, free the "result" string when done with it, to avoid a permanent memory leak. Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
2011-05-12 17:56:38 +02:00
free(result);
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
if (state == 5 || state == 6)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("unterminated quoted string in connection info string\n"));
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
return 3;
}
return 0;
}
Fix unused-variable warning on Windows. Introduced in 585bca39: msgid is not used in the Windows code path. Also adjust comments a tad (mostly to keep pgindent from messing it up). David Rowley
2014-04-17 22:12:24 +02:00
#endif /* USE_LDAP */
Locate the file pg_service.conf in the directory configured as --syconfdir (i.e., /usr/local/pgsql/etc by default).
2000-10-17 19:43:13 +02:00
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
/*
* parseServiceInfo: if a service name has been given, look it up and absorb
* connection options from it into *options.
*
* Returns 0 on success, nonzero on failure. On failure, if errorMessage
* isn't null, also store an error message there. (Note: the only reason
* this function and related ones don't dump core on errorMessage == NULL
Rearrange libpq's error reporting to avoid duplicated error text. Since commit ffa2e4670, libpq accumulates text in conn->errorMessage across a whole query cycle. In some situations, we may report more than one error event within a cycle: the easiest case to reach is where we report a FATAL error message from the server, and then a bit later we detect loss of connection. Since, historically, each error PGresult bears the entire content of conn->errorMessage, this results in duplication of the FATAL message in any output that concatenates the contents of the PGresults. Accumulation in errorMessage still seems like a good idea, especially in view of the number of places that did ad-hoc error concatenation before ffa2e4670. So to fix this, let's track how much of conn->errorMessage has been read out into error PGresults, and only include new text in later PGresults. The tricky part of that is to be sure that we never discard an error PGresult once made (else we'd risk dropping some text, a problem much worse than duplication). While libpq formerly did that in some code paths, a little bit of rearrangement lets us postpone making an error PGresult at all until we are about to return it. A side benefit of that postponement is that it now becomes practical to return a dummy static PGresult in cases where we hit out-of-memory while trying to manufacture an error PGresult. This eliminates the admittedly-very-rare case where we'd return NULL from PQgetResult, indicating successful query completion, even though what actually happened was an OOM failure. Discussion: https://postgr.es/m/ab4288f8-be5c-57fb-2400-e3e857f53e46@enterprisedb.com
2022-02-18 21:35:15 +01:00
* is the undocumented fact that appendPQExpBuffer does nothing when passed
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
* a null PQExpBuffer pointer.)
*/
Silence compiler warning.
2000-12-07 03:04:30 +01:00
static int
parseServiceInfo(PQconninfoOption *options, PQExpBuffer errorMessage)
{
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
const char *service = conninfo_getval(options, "service");
Add PGETC (for pg_service.conf) and PGLOCALE (for locale dir) environment variable processing to libpq. The patch also adds code to our client apps so we set the environment variable directly based on our binary location, unless it is already set. This will allow our applications to emit proper locale messages that are generated in libpq.
2004-06-03 02:07:38 +02:00
char serviceFile[MAXPGPATH];
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
char *env;
Prevent service dbname from defaulting to service name, per bug report from Michael Fuhr
2003-12-19 22:50:54 +01:00
bool group_found = false;
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
int status;
struct stat stat_buf;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Missed some corner cases (PGSERVICE mostly)...
2003-04-28 06:52:13 +02:00
/*
* We have to special-case the environment variable PGSERVICE here, since
* this is and should be called before inserting environment defaults for
* other connection options.
*/
if (service == NULL)
service = getenv("PGSERVICE");
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
/* If no service name given, nothing to do */
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
if (service == NULL)
return 0;
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
/*
* Try PGSERVICEFILE if specified, else try ~/.pg_service.conf (if that
* exists).
*/
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
if ((env = getenv("PGSERVICEFILE")) != NULL)
strlcpy(serviceFile, env, sizeof(serviceFile));
else
{
char homedir[MAXPGPATH];
if (!pqGetHomeDirectory(homedir, sizeof(homedir)))
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
goto next_file;
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
snprintf(serviceFile, MAXPGPATH, "%s/%s", homedir, ".pg_service.conf");
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
if (stat(serviceFile, &stat_buf) != 0)
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
goto next_file;
}
status = parseServiceFile(serviceFile, service, options, errorMessage, &group_found);
if (group_found || status != 0)
return status;
next_file:
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Add PGETC (for pg_service.conf) and PGLOCALE (for locale dir) environment variable processing to libpq. The patch also adds code to our client apps so we set the environment variable directly based on our binary location, unless it is already set. This will allow our applications to emit proper locale messages that are generated in libpq.
2004-06-03 02:07:38 +02:00
/*
* This could be used by any application so we can't use the binary
* location to find our config files.
*/
snprintf(serviceFile, MAXPGPATH, "%s/pg_service.conf",
libpq was not consistently checking for memory allocation failures. This patch adds missing checks to the call sites of malloc(), strdup(), PQmakeEmptyPGresult(), pqResultAlloc(), and pqResultStrdup(), and updates the documentation. Per original report from Volkan Yazici about PQmakeEmptyPGresult() not checking for malloc() failure.
2005-06-12 02:00:21 +02:00
getenv("PGSYSCONFDIR") ? getenv("PGSYSCONFDIR") : SYSCONFDIR);
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
if (stat(serviceFile, &stat_buf) != 0)
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
goto last_file;
status = parseServiceFile(serviceFile, service, options, errorMessage, &group_found);
if (status != 0)
return status;
last_file:
if (!group_found)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
libpq_gettext("definition of service \"%s\" not found\n"), service);
return 3;
}
return 0;
}
static int
parseServiceFile(const char *serviceFile,
const char *service,
PQconninfoOption *options,
PQExpBuffer errorMessage,
bool *group_found)
{
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
int result = 0,
linenr = 0,
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
i;
FILE *f;
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
char *line;
Remove undesirable libpq dependency on stringinfo.c. Commit c0cb87fbb unwisely introduced a dependency on the StringInfo machinery in fe-connect.c. We must not use that in libpq, because it will do a summary exit(1) if it hits OOM, and that is not appropriate behavior for a general-purpose library. The goal of allowing arbitrary line lengths in service files doesn't seem like it's worth a lot of effort, so revert back to the previous method of using a stack-allocated buffer and failing on buffer overflow. This isn't an exact revert though. I kept that patch's refactoring to have a single exit path, as that seems cleaner than having each error path know what to do to clean up. Also, I made the fixed-size buffer 1024 bytes not 256, just to push off the need for an expandable buffer some more. There is more to do here; in particular the lack of any mechanical check for this type of mistake now seems pretty hazardous. But this fix gets us back to the level of robustness we had in v13, anyway. Discussion: https://postgr.es/m/daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com
2021-06-26 20:20:17 +02:00
char buf[1024];
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
*group_found = false;
Add PGETC (for pg_service.conf) and PGLOCALE (for locale dir) environment variable processing to libpq. The patch also adds code to our client apps so we set the environment variable directly based on our binary location, unless it is already set. This will allow our applications to emit proper locale messages that are generated in libpq.
2004-06-03 02:07:38 +02:00
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
f = fopen(serviceFile, "r");
if (f == NULL)
TNS: I prepared and tested a patch vs. 7.0.2, and it works fine. I've added another option which allows users to have their own service file in ~/.pg_service.conf, which might come handy sometimes. Mario Weilguni
2000-10-17 03:00:58 +02:00
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage, libpq_gettext("service file \"%s\" not found\n"),
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
serviceFile);
return 1;
}
Remove undesirable libpq dependency on stringinfo.c. Commit c0cb87fbb unwisely introduced a dependency on the StringInfo machinery in fe-connect.c. We must not use that in libpq, because it will do a summary exit(1) if it hits OOM, and that is not appropriate behavior for a general-purpose library. The goal of allowing arbitrary line lengths in service files doesn't seem like it's worth a lot of effort, so revert back to the previous method of using a stack-allocated buffer and failing on buffer overflow. This isn't an exact revert though. I kept that patch's refactoring to have a single exit path, as that seems cleaner than having each error path know what to do to clean up. Also, I made the fixed-size buffer 1024 bytes not 256, just to push off the need for an expandable buffer some more. There is more to do here; in particular the lack of any mechanical check for this type of mistake now seems pretty hazardous. But this fix gets us back to the level of robustness we had in v13, anyway. Discussion: https://postgr.es/m/daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com
2021-06-26 20:20:17 +02:00
while ((line = fgets(buf, sizeof(buf), f)) != NULL)
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
{
Remove undesirable libpq dependency on stringinfo.c. Commit c0cb87fbb unwisely introduced a dependency on the StringInfo machinery in fe-connect.c. We must not use that in libpq, because it will do a summary exit(1) if it hits OOM, and that is not appropriate behavior for a general-purpose library. The goal of allowing arbitrary line lengths in service files doesn't seem like it's worth a lot of effort, so revert back to the previous method of using a stack-allocated buffer and failing on buffer overflow. This isn't an exact revert though. I kept that patch's refactoring to have a single exit path, as that seems cleaner than having each error path know what to do to clean up. Also, I made the fixed-size buffer 1024 bytes not 256, just to push off the need for an expandable buffer some more. There is more to do here; in particular the lack of any mechanical check for this type of mistake now seems pretty hazardous. But this fix gets us back to the level of robustness we had in v13, anyway. Discussion: https://postgr.es/m/daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com
2021-06-26 20:20:17 +02:00
int len;
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
linenr++;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Remove undesirable libpq dependency on stringinfo.c. Commit c0cb87fbb unwisely introduced a dependency on the StringInfo machinery in fe-connect.c. We must not use that in libpq, because it will do a summary exit(1) if it hits OOM, and that is not appropriate behavior for a general-purpose library. The goal of allowing arbitrary line lengths in service files doesn't seem like it's worth a lot of effort, so revert back to the previous method of using a stack-allocated buffer and failing on buffer overflow. This isn't an exact revert though. I kept that patch's refactoring to have a single exit path, as that seems cleaner than having each error path know what to do to clean up. Also, I made the fixed-size buffer 1024 bytes not 256, just to push off the need for an expandable buffer some more. There is more to do here; in particular the lack of any mechanical check for this type of mistake now seems pretty hazardous. But this fix gets us back to the level of robustness we had in v13, anyway. Discussion: https://postgr.es/m/daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com
2021-06-26 20:20:17 +02:00
if (strlen(line) >= sizeof(buf) - 1)
{
appendPQExpBuffer(errorMessage,
libpq_gettext("line %d too long in service file \"%s\"\n"),
linenr,
serviceFile);
result = 2;
goto exit;
}
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
Remove undesirable libpq dependency on stringinfo.c. Commit c0cb87fbb unwisely introduced a dependency on the StringInfo machinery in fe-connect.c. We must not use that in libpq, because it will do a summary exit(1) if it hits OOM, and that is not appropriate behavior for a general-purpose library. The goal of allowing arbitrary line lengths in service files doesn't seem like it's worth a lot of effort, so revert back to the previous method of using a stack-allocated buffer and failing on buffer overflow. This isn't an exact revert though. I kept that patch's refactoring to have a single exit path, as that seems cleaner than having each error path know what to do to clean up. Also, I made the fixed-size buffer 1024 bytes not 256, just to push off the need for an expandable buffer some more. There is more to do here; in particular the lack of any mechanical check for this type of mistake now seems pretty hazardous. But this fix gets us back to the level of robustness we had in v13, anyway. Discussion: https://postgr.es/m/daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com
2021-06-26 20:20:17 +02:00
/* ignore whitespace at end of line, especially the newline */
len = strlen(line);
while (len > 0 && isspace((unsigned char) line[len - 1]))
line[--len] = '\0';
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Fix failures to ignore \r when reading Windows-style newlines. libpq failed to ignore Windows-style newlines in connection service files. This normally wasn't a problem on Windows itself, because fgets() would convert \r\n to just \n. But if libpq were running inside a program that changes the default fopen mode to binary, it would see the \r's and think they were data. In any case, it's project policy to ignore \r in text files unconditionally, because people sometimes try to use files with DOS-style newlines on Unix machines, where the C library won't hide that from us. Hence, adjust parseServiceFile() to ignore \r as well as \n at the end of the line. In HEAD, go a little further and make it ignore all trailing whitespace, to match what it's always done with leading whitespace. In HEAD, also run around and fix up everyplace where we have newline-chomping code to make all those places look consistent and uniformly drop \r. It is not clear whether any of those changes are fixing live bugs. Most of the non-cosmetic changes are in places that are reading popen output, and the jury is still out as to whether popen on Windows can return \r\n. (The Windows-specific code in pipe_read_line seems to think so, but our lack of support for this elsewhere suggests maybe it's not a problem in practice.) Hence, I desisted from applying those changes to back branches, except in run_ssl_passphrase_command() which is new enough and little-tested enough that we'd probably not have heard about any problems there. Tom Lane and Michael Paquier, per bug #15827 from Jorge Gustavo Rocha. Back-patch the parseServiceFile() change to all supported branches, and the run_ssl_passphrase_command() change to v11 where that was added. Discussion: https://postgr.es/m/15827-e6ba53a3a7ed543c@postgresql.org
2019-07-25 18:10:54 +02:00
/* ignore leading whitespace too */
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
while (*line && isspace((unsigned char) line[0]))
line++;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
/* ignore comments and empty lines */
Fix failures to ignore \r when reading Windows-style newlines. libpq failed to ignore Windows-style newlines in connection service files. This normally wasn't a problem on Windows itself, because fgets() would convert \r\n to just \n. But if libpq were running inside a program that changes the default fopen mode to binary, it would see the \r's and think they were data. In any case, it's project policy to ignore \r in text files unconditionally, because people sometimes try to use files with DOS-style newlines on Unix machines, where the C library won't hide that from us. Hence, adjust parseServiceFile() to ignore \r as well as \n at the end of the line. In HEAD, go a little further and make it ignore all trailing whitespace, to match what it's always done with leading whitespace. In HEAD, also run around and fix up everyplace where we have newline-chomping code to make all those places look consistent and uniformly drop \r. It is not clear whether any of those changes are fixing live bugs. Most of the non-cosmetic changes are in places that are reading popen output, and the jury is still out as to whether popen on Windows can return \r\n. (The Windows-specific code in pipe_read_line seems to think so, but our lack of support for this elsewhere suggests maybe it's not a problem in practice.) Hence, I desisted from applying those changes to back branches, except in run_ssl_passphrase_command() which is new enough and little-tested enough that we'd probably not have heard about any problems there. Tom Lane and Michael Paquier, per bug #15827 from Jorge Gustavo Rocha. Back-patch the parseServiceFile() change to all supported branches, and the run_ssl_passphrase_command() change to v11 where that was added. Discussion: https://postgr.es/m/15827-e6ba53a3a7ed543c@postgresql.org
2019-07-25 18:10:54 +02:00
if (line[0] == '\0' || line[0] == '#')
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
continue;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
/* Check for right groupname */
if (line[0] == '[')
{
if (*group_found)
TNS: I prepared and tested a patch vs. 7.0.2, and it works fine. I've added another option which allows users to have their own service file in ~/.pg_service.conf, which might come handy sometimes. Mario Weilguni
2000-10-17 03:00:58 +02:00
{
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
/* end of desired group reached; return success */
goto exit;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
}
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
if (strncmp(line + 1, service, strlen(service)) == 0 &&
line[strlen(service) + 1] == ']')
*group_found = true;
TNS: I prepared and tested a patch vs. 7.0.2, and it works fine. I've added another option which allows users to have their own service file in ~/.pg_service.conf, which might come handy sometimes. Mario Weilguni
2000-10-17 03:00:58 +02:00
else
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
*group_found = false;
}
else
{
if (*group_found)
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
{
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
/*
* Finally, we are in the right group and can parse the line
*/
char *key,
*val;
bool found_keyword;
TNS: I prepared and tested a patch vs. 7.0.2, and it works fine. I've added another option which allows users to have their own service file in ~/.pg_service.conf, which might come handy sometimes. Mario Weilguni
2000-10-17 03:00:58 +02:00
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
#ifdef USE_LDAP
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
if (strncmp(line, "ldap", 4) == 0)
{
int rc = ldapServiceLookup(line, options, errorMessage);
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
/* if rc = 2, go on reading for fallback */
switch (rc)
{
case 0:
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
goto exit;
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
case 1:
case 3:
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
result = 3;
goto exit;
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
case 2:
continue;
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
}
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
}
Allow LDAP lookups from pg_service.conf. Albe Laurenz
2006-07-27 15:20:24 +02:00
#endif
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
key = line;
val = strchr(line, '=');
if (val == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
libpq_gettext("syntax error in service file \"%s\", line %d\n"),
serviceFile,
linenr);
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
result = 3;
goto exit;
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
}
*val++ = '\0';
Only set the database name if we find a match in the services file.
2003-01-08 17:21:53 +01:00
libpq: issue clear error message for nested service files Previously an odd error message was generated. Nested service files are not supported. Report by David Johnston
2015-04-08 16:26:21 +02:00
if (strcmp(key, "service") == 0)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
libpq: issue clear error message for nested service files Previously an odd error message was generated. Nested service files are not supported. Report by David Johnston
2015-04-08 16:26:21 +02:00
libpq_gettext("nested service specifications not supported in service file \"%s\", line %d\n"),
serviceFile,
linenr);
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
result = 3;
goto exit;
libpq: issue clear error message for nested service files Previously an odd error message was generated. Nested service files are not supported. Report by David Johnston
2015-04-08 16:26:21 +02:00
}
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
/*
* Set the parameter --- but don't override any previous
* explicit setting.
*/
found_keyword = false;
for (i = 0; options[i].keyword; i++)
{
if (strcmp(options[i].keyword, key) == 0)
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
{
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
if (options[i].val == NULL)
options[i].val = strdup(val);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!options[i].val)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
result = 3;
goto exit;
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
}
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
found_keyword = true;
break;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
}
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
}
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
if (!found_keyword)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
libpq_gettext("syntax error in service file \"%s\", line %d\n"),
serviceFile,
linenr);
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
result = 3;
goto exit;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
}
}
}
}
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
exit:
Add user-specific .pg_service.conf file This extends the existing pg_service.conf facility to first look for a service definition file in the user's home directory.
2010-01-20 22:15:21 +01:00
fclose(f);
Remove arbitrary line length limit for libpq service files. Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-22 21:59:23 +02:00
return result;
TNS: I prepared and tested a patch vs. 7.0.2, and it works fine. I've added another option which allows users to have their own service file in ~/.pg_service.conf, which might come handy sometimes. Mario Weilguni
2000-10-17 03:00:58 +02:00
}
From: Phil Thompson <phil@river-bank.demon.co.uk> I've completed the patch to fix the protocol and authentication issues I was discussing a couple of weeks ago. The particular changes are: - the protocol has a version number - network byte order is used throughout - the pg_hba.conf file is used to specify what method is used to authenticate a frontend (either password, ident, trust, reject, krb4 or krb5) - support for multiplexed backends is removed - appropriate changes to man pages - the -a switch to many programs to specify an authentication service no longer has any effect - the libpq.so version number has changed to 1.1 The new backend still supports the old protocol so old interfaces won't break.
1998-01-26 02:42:53 +01:00
Fix dblink_connect() so that it verifies that a password is supplied in the conninfo string *before* trying to connect to the remote server, not after. As pointed out by Marko Kreen, in certain not-very-plausible situations this could result in sending a password from the postgres user's .pgpass file, or other places that non-superusers shouldn't have access to, to an untrustworthy remote server. The cleanest fix seems to be to expose libpq's conninfo-string-parsing code so that dblink can check for a password option without duplicating the parsing logic. Joe Conway, with a little cleanup by Tom Lane
2008-09-22 15:55:14 +02:00
/*
* PQconninfoParse
*
* Parse a string like PQconnectdb() would do and return the
* resulting connection options array. NULL is returned on failure.
* The result contains only options specified directly in the string,
* not any possible default values.
*
* If errmsg isn't NULL, *errmsg is set to NULL on success, or a malloc'd
* string on failure (use PQfreemem to free it). In out-of-memory conditions
* both *errmsg and the result could be NULL.
*
* NOTE: the returned array is dynamically allocated and should
* be freed when no longer needed via PQconninfoFree().
*/
PQconninfoOption *
PQconninfoParse(const char *conninfo, char **errmsg)
{
PQExpBufferData errorBuf;
PQconninfoOption *connOptions;
if (errmsg)
*errmsg = NULL; /* default */
initPQExpBuffer(&errorBuf);
Suppress remaining -Waddress warnings from recent gcc versions. Still an exercise in satisfying pedants.
2011-10-19 03:44:23 +02:00
if (PQExpBufferDataBroken(errorBuf))
Fix dblink_connect() so that it verifies that a password is supplied in the conninfo string *before* trying to connect to the remote server, not after. As pointed out by Marko Kreen, in certain not-very-plausible situations this could result in sending a password from the postgres user's .pgpass file, or other places that non-superusers shouldn't have access to, to an untrustworthy remote server. The cleanest fix seems to be to expose libpq's conninfo-string-parsing code so that dblink can check for a password option without duplicating the parsing logic. Joe Conway, with a little cleanup by Tom Lane
2008-09-22 15:55:14 +02:00
return NULL; /* out of memory already :-( */
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
connOptions = parse_connection_string(conninfo, &errorBuf, false);
Fix dblink_connect() so that it verifies that a password is supplied in the conninfo string *before* trying to connect to the remote server, not after. As pointed out by Marko Kreen, in certain not-very-plausible situations this could result in sending a password from the postgres user's .pgpass file, or other places that non-superusers shouldn't have access to, to an untrustworthy remote server. The cleanest fix seems to be to expose libpq's conninfo-string-parsing code so that dblink can check for a password option without duplicating the parsing logic. Joe Conway, with a little cleanup by Tom Lane
2008-09-22 15:55:14 +02:00
if (connOptions == NULL && errmsg)
*errmsg = errorBuf.data;
else
termPQExpBuffer(&errorBuf);
return connOptions;
}
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
/*
* Build a working copy of the constant PQconninfoOptions array.
*/
static PQconninfoOption *
conninfo_init(PQExpBuffer errorMessage)
{
PQconninfoOption *options;
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
PQconninfoOption *opt_dest;
const internalPQconninfoOption *cur_opt;
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
/*
* Get enough memory for all options in PQconninfoOptions, even if some
* end up being filtered out.
*/
options = (PQconninfoOption *) malloc(sizeof(PQconninfoOption) * sizeof(PQconninfoOptions) / sizeof(PQconninfoOptions[0]));
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
if (options == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
return NULL;
}
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
opt_dest = options;
for (cur_opt = PQconninfoOptions; cur_opt->keyword; cur_opt++)
{
/* Only copy the public part of the struct, not the full internal */
memcpy(opt_dest, cur_opt, sizeof(PQconninfoOption));
opt_dest++;
}
MemSet(opt_dest, 0, sizeof(PQconninfoOption));
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
return options;
}
Remove some unneeded dashes from libpq comments.
2001-08-17 17:11:15 +02:00
/*
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
* Connection string parser
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
*
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
* Returns a malloc'd PQconninfoOption array, if parsing is successful.
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
* Otherwise, NULL is returned and an error message is added to errorMessage.
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
*
Change TRUE/FALSE to true/false The lower case spellings are C and C++ standard and are used in most parts of the PostgreSQL sources. The upper case spellings are only used in some files/modules. So standardize on the standard spellings. The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so those are left as is when using those APIs. In code comments, we use the lower-case spelling for the C concepts and keep the upper-case spelling for the SQL concepts. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-08-16 06:22:32 +02:00
* If use_defaults is true, default values are filled in (from a service file,
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
* environment variables, etc).
*/
static PQconninfoOption *
parse_connection_string(const char *connstr, PQExpBuffer errorMessage,
bool use_defaults)
{
/* Parse as URI if connection string matches URI prefix */
Revert "psql: fix \connect with URIs and conninfo strings" This reverts commit fcef1617295c074f2684c887627184d2fc26ac04, about which both the buildfarm and my local machine are very unhappy.
2015-04-02 16:10:22 +02:00
if (uri_prefix_length(connstr) != 0)
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
return conninfo_uri_parse(connstr, errorMessage, use_defaults);
/* Parse as default otherwise */
return conninfo_parse(connstr, errorMessage, use_defaults);
}
Revert "psql: fix \connect with URIs and conninfo strings" This reverts commit fcef1617295c074f2684c887627184d2fc26ac04, about which both the buildfarm and my local machine are very unhappy.
2015-04-02 16:10:22 +02:00
/*
* Checks if connection string starts with either of the valid URI prefix
* designators.
*
* Returns the URI prefix length, 0 if the string doesn't contain a URI prefix.
psql: fix \connect with URIs and conninfo strings This is the second try at this, after fcef1617295 failed miserably and had to be reverted: as it turns out, libpq cannot depend on libpgcommon after all. Instead of shuffling code in the master branch, make that one just like 9.4 and accept the duplication. (This was all my own mistake, not the patch submitter's). psql was already accepting conninfo strings as the first parameter in \connect, but the way it worked wasn't sane; some of the other parameters would get the previous connection's values, causing it to connect to a completely unexpected server or, more likely, not finding any server at all because of completely wrong combinations of parameters. Fix by explicitely checking for a conninfo-looking parameter in the dbname position; if one is found, use its complete specification rather than mix with the other arguments. Also, change tab-completion to not try to complete conninfo/URI-looking "dbnames" and document that conninfos are accepted as first argument. There was a weak consensus to backpatch this, because while the behavior of using the dbname as a conninfo is nowhere documented for \connect, it is reasonable to expect that it works because it does work in many other contexts. Therefore this is backpatched all the way back to 9.0. Author: David Fetter, Andrew Dunstan. Some editorialization by me (probably earning a Gierth's "Sloppy" badge in the process.) Reviewers: Andrew Gierth, Erik Rijkers, Pavel Stěhule, Stephen Frost, Robert Haas, Andrew Dunstan.
2015-04-02 17:30:57 +02:00
*
* XXX this is duplicated in psql/common.c.
Revert "psql: fix \connect with URIs and conninfo strings" This reverts commit fcef1617295c074f2684c887627184d2fc26ac04, about which both the buildfarm and my local machine are very unhappy.
2015-04-02 16:10:22 +02:00
*/
static int
uri_prefix_length(const char *connstr)
{
if (strncmp(connstr, uri_designator,
sizeof(uri_designator) - 1) == 0)
return sizeof(uri_designator) - 1;
if (strncmp(connstr, short_uri_designator,
sizeof(short_uri_designator) - 1) == 0)
return sizeof(short_uri_designator) - 1;
return 0;
}
/*
* Recognized connection string either starts with a valid URI prefix or
* contains a "=" in it.
*
* Must be consistent with parse_connection_string: anything for which this
* returns true should at least look like it's parseable by that routine.
psql: fix \connect with URIs and conninfo strings This is the second try at this, after fcef1617295 failed miserably and had to be reverted: as it turns out, libpq cannot depend on libpgcommon after all. Instead of shuffling code in the master branch, make that one just like 9.4 and accept the duplication. (This was all my own mistake, not the patch submitter's). psql was already accepting conninfo strings as the first parameter in \connect, but the way it worked wasn't sane; some of the other parameters would get the previous connection's values, causing it to connect to a completely unexpected server or, more likely, not finding any server at all because of completely wrong combinations of parameters. Fix by explicitely checking for a conninfo-looking parameter in the dbname position; if one is found, use its complete specification rather than mix with the other arguments. Also, change tab-completion to not try to complete conninfo/URI-looking "dbnames" and document that conninfos are accepted as first argument. There was a weak consensus to backpatch this, because while the behavior of using the dbname as a conninfo is nowhere documented for \connect, it is reasonable to expect that it works because it does work in many other contexts. Therefore this is backpatched all the way back to 9.0. Author: David Fetter, Andrew Dunstan. Some editorialization by me (probably earning a Gierth's "Sloppy" badge in the process.) Reviewers: Andrew Gierth, Erik Rijkers, Pavel Stěhule, Stephen Frost, Robert Haas, Andrew Dunstan.
2015-04-02 17:30:57 +02:00
*
* XXX this is duplicated in psql/common.c
Revert "psql: fix \connect with URIs and conninfo strings" This reverts commit fcef1617295c074f2684c887627184d2fc26ac04, about which both the buildfarm and my local machine are very unhappy.
2015-04-02 16:10:22 +02:00
*/
static bool
recognized_connection_string(const char *connstr)
{
return uri_prefix_length(connstr) != 0 || strchr(connstr, '=') != NULL;
}
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
/*
* Subroutine for parse_connection_string
*
* Deal with a string containing key=value pairs.
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*/
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
static PQconninfoOption *
Fix up the PQconnectionUsedPassword mess: create a separate PQconnectionNeedsPassword function that tells the right thing for whether to prompt for a password, and improve PQconnectionUsedPassword so that it checks whether the password used by the connection was actually supplied as a connection argument, instead of coming from environment or a password file. Per bug report from Mark Cave-Ayland and subsequent discussion.
2007-12-09 20:01:40 +01:00
conninfo_parse(const char *conninfo, PQExpBuffer errorMessage,
Get rid of pgpass_from_client tracking inside libpq --- given the conclusion that presence of the password in the conninfo string must be checked *before* risking a connection attempt, there is no point in checking it afterwards. This makes the specification of PQconnectionUsedPassword() a bit simpler and perhaps more generally useful, too.
2008-09-22 16:21:44 +02:00
bool use_defaults)
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{
char *pname;
char *pval;
char *buf;
char *cp;
char *cp2;
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
PQconninfoOption *options;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
/* Make a working copy of PQconninfoOptions */
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
options = conninfo_init(errorMessage);
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
if (options == NULL)
return NULL;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
/* Need a modifiable copy of the input string */
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
if ((buf = strdup(conninfo)) == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
PQconninfoFree(options);
return NULL;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
}
cp = buf;
while (*cp)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
/* Skip blanks before the parameter name */
Ensure that all uses of <ctype.h> functions are applied to unsigned-char values, whether the local char type is signed or not. This is necessary for portability. Per discussion on pghackers around 9/16/00.
2000-12-03 21:45:40 +01:00
if (isspace((unsigned char) *cp))
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{
cp++;
continue;
}
/* Get the parameter name */
pname = cp;
while (*cp)
{
if (*cp == '=')
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
break;
Ensure that all uses of <ctype.h> functions are applied to unsigned-char values, whether the local char type is signed or not. This is necessary for portability. Per discussion on pghackers around 9/16/00.
2000-12-03 21:45:40 +01:00
if (isspace((unsigned char) *cp))
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*cp++ = '\0';
while (*cp)
{
Ensure that all uses of <ctype.h> functions are applied to unsigned-char values, whether the local char type is signed or not. This is necessary for portability. Per discussion on pghackers around 9/16/00.
2000-12-03 21:45:40 +01:00
if (!isspace((unsigned char) *cp))
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
break;
cp++;
}
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
break;
}
cp++;
}
/* Check that there is a following '=' */
if (*cp != '=')
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
NLS for libpq. Clean up the message formats and change the documentation accordingly.
2001-07-15 15:45:04 +02:00
libpq_gettext("missing \"=\" after \"%s\" in connection info string\n"),
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
pname);
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
PQconninfoFree(options);
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
free(buf);
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
return NULL;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*cp++ = '\0';
/* Skip blanks after the '=' */
while (*cp)
{
Ensure that all uses of <ctype.h> functions are applied to unsigned-char values, whether the local char type is signed or not. This is necessary for portability. Per discussion on pghackers around 9/16/00.
2000-12-03 21:45:40 +01:00
if (!isspace((unsigned char) *cp))
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
break;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
cp++;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
/* Get the parameter value */
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
pval = cp;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
if (*cp != '\'')
{
cp2 = pval;
while (*cp)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Ensure that all uses of <ctype.h> functions are applied to unsigned-char values, whether the local char type is signed or not. This is necessary for portability. Per discussion on pghackers around 9/16/00.
2000-12-03 21:45:40 +01:00
if (isspace((unsigned char) *cp))
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*cp++ = '\0';
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
break;
}
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
if (*cp == '\\')
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
cp++;
if (*cp != '\0')
*cp2++ = *cp++;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
else
*cp2++ = *cp++;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*cp2 = '\0';
}
else
{
cp2 = pval;
cp++;
for (;;)
{
if (*cp == '\0')
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("unterminated quoted string in connection info string\n"));
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
PQconninfoFree(options);
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
free(buf);
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
return NULL;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
if (*cp == '\\')
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
cp++;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
if (*cp != '\0')
*cp2++ = *cp++;
continue;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
if (*cp == '\'')
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*cp2 = '\0';
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
cp++;
break;
}
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*cp2++ = *cp++;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
/*
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
* Now that we have the name and the value, store the record.
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*/
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
if (!conninfo_storeval(options, pname, pval, errorMessage, false, false))
libpq was not consistently checking for memory allocation failures. This patch adds missing checks to the call sites of malloc(), strdup(), PQmakeEmptyPGresult(), pqResultAlloc(), and pqResultStrdup(), and updates the documentation. Per original report from Volkan Yazici about PQmakeEmptyPGresult() not checking for malloc() failure.
2005-06-12 02:00:21 +02:00
{
PQconninfoFree(options);
free(buf);
return NULL;
}
TNS: I prepared and tested a patch vs. 7.0.2, and it works fine. I've added another option which allows users to have their own service file in ~/.pg_service.conf, which might come handy sometimes. Mario Weilguni
2000-10-17 03:00:58 +02:00
}
Okay, I've had it with PQsetdbLogin having slightly different defaults than PQconnectdb. Reimplement the former to use the same code as the latter. Fix documentation omissions while at it.
2003-04-28 06:29:12 +02:00
/* Done with the modifiable input string */
free(buf);
Fix dblink_connect() so that it verifies that a password is supplied in the conninfo string *before* trying to connect to the remote server, not after. As pointed out by Marko Kreen, in certain not-very-plausible situations this could result in sending a password from the postgres user's .pgpass file, or other places that non-superusers shouldn't have access to, to an untrustworthy remote server. The cleanest fix seems to be to expose libpq's conninfo-string-parsing code so that dblink can check for a password option without duplicating the parsing logic. Joe Conway, with a little cleanup by Tom Lane
2008-09-22 15:55:14 +02:00
/*
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
* Add in defaults if the caller wants that.
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
*/
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
if (use_defaults)
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
if (!conninfo_add_defaults(options, errorMessage))
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
PQconninfoFree(options);
return NULL;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
}
}
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
return options;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
}
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
/*
* Conninfo array parser routine
*
* If successful, a malloc'd PQconninfoOption array is returned.
* If not successful, NULL is returned and an error message is
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
* appended to errorMessage.
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
* Defaults are supplied (from a service file, environment variables, etc)
Change TRUE/FALSE to true/false The lower case spellings are C and C++ standard and are used in most parts of the PostgreSQL sources. The upper case spellings are only used in some files/modules. So standardize on the standard spellings. The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so those are left as is when using those APIs. In code comments, we use the lower-case spelling for the C concepts and keep the upper-case spelling for the SQL concepts. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-08-16 06:22:32 +02:00
* for unspecified options, but only if use_defaults is true.
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
*
Allow "dbname" from connection string to be overridden in PQconnectDBParams If the "dbname" attribute in PQconnectDBParams contained a connection string or URI (and expand_dbname = TRUE), the database name from the connection string could not be overridden by a subsequent "dbname" keyword in the array. That was not intentional; all other options can be overridden. Furthermore, any subsequent "dbname" caused the connection string from the first dbname value to be processed again, overriding any values for the same options that were given between the connection string and the second dbname option. In the passing, clarify in the docs that only the first dbname option in the array is parsed as a connection string. Alex Shulgin. Backpatch to all supported versions.
2014-11-25 16:12:07 +01:00
* If expand_dbname is non-zero, and the value passed for the first occurrence
* of "dbname" keyword is a connection string (as indicated by
Revert "psql: fix \connect with URIs and conninfo strings" This reverts commit fcef1617295c074f2684c887627184d2fc26ac04, about which both the buildfarm and my local machine are very unhappy.
2015-04-02 16:10:22 +02:00
* recognized_connection_string) then parse and process it, overriding any
Allow "dbname" from connection string to be overridden in PQconnectDBParams If the "dbname" attribute in PQconnectDBParams contained a connection string or URI (and expand_dbname = TRUE), the database name from the connection string could not be overridden by a subsequent "dbname" keyword in the array. That was not intentional; all other options can be overridden. Furthermore, any subsequent "dbname" caused the connection string from the first dbname value to be processed again, overriding any values for the same options that were given between the connection string and the second dbname option. In the passing, clarify in the docs that only the first dbname option in the array is parsed as a connection string. Alex Shulgin. Backpatch to all supported versions.
2014-11-25 16:12:07 +01:00
* previously processed conflicting keywords. Subsequent keywords will take
Obstruct shell, SQL, and conninfo injection via database and role names. Due to simplistic quoting and confusion of database names with conninfo strings, roles with the CREATEDB or CREATEROLE option could escalate to superuser privileges when a superuser next ran certain maintenance commands. The new coding rule for PQconnectdbParams() calls, documented at conninfo_array_parse(), is to pass expand_dbname=true and wrap literal database names in a trivial connection string. Escape zero-length values in appendConnStrVal(). Back-patch to 9.1 (all supported versions). Nathan Bossart, Michael Paquier, and Noah Misch. Reviewed by Peter Eisentraut. Reported by Nathan Bossart. Security: CVE-2016-5424
2016-08-08 16:07:46 +02:00
* precedence, however. In-tree programs generally specify expand_dbname=true,
* so command-line arguments naming a database can use a connection string.
* Some code acquires arbitrary database names from known-literal sources like
* PQdb(), PQconninfoParse() and pg_database.datname. When connecting to such
* a database, in-tree code first wraps the name in a connection string.
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
*/
static PQconninfoOption *
Fully const-ify PQconnectdbParams, PQconnectStartParams, and PQpingParams. The keywords and values arguments of these functions are more properly declared "const char * const *" than just "const char **". Lionel Elie Mamane, reviewed by Craig Ringer
2011-09-26 00:52:48 +02:00
conninfo_array_parse(const char *const *keywords, const char *const *values,
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
PQExpBuffer errorMessage, bool use_defaults,
int expand_dbname)
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
{
PQconninfoOption *options;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
PQconninfoOption *dbname_options = NULL;
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
PQconninfoOption *option;
int i = 0;
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
/*
* If expand_dbname is non-zero, check keyword "dbname" to see if val is
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
* actually a recognized connection string.
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
*/
while (expand_dbname && keywords[i])
{
const char *pname = keywords[i];
const char *pvalue = values[i];
/* first find "dbname" if any */
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
if (strcmp(pname, "dbname") == 0 && pvalue)
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
{
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
/*
* If value is a connection string, parse it, but do not use
* defaults here -- those get picked up later. We only want to
* override for those parameters actually passed.
*/
Revert "psql: fix \connect with URIs and conninfo strings" This reverts commit fcef1617295c074f2684c887627184d2fc26ac04, about which both the buildfarm and my local machine are very unhappy.
2015-04-02 16:10:22 +02:00
if (recognized_connection_string(pvalue))
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
{
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
dbname_options = parse_connection_string(pvalue, errorMessage, false);
if (dbname_options == NULL)
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
return NULL;
}
break;
}
++i;
}
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
/* Make a working copy of PQconninfoOptions */
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
options = conninfo_init(errorMessage);
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
if (options == NULL)
{
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
PQconninfoFree(dbname_options);
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
return NULL;
}
/* Parse the keywords/values arrays */
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
i = 0;
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
while (keywords[i])
{
const char *pname = keywords[i];
const char *pvalue = values[i];
libpq: have PQconnectdbParams() and PQpingParams accept "" as default Previously, these functions treated "" optin values as defaults in some ways, but not in others, like when comparing to .pgpass. Also, add documentation to clarify that now "" and NULL use defaults, like PQsetdbLogin() has always done. BACKWARD INCOMPATIBILITY Patch by Adrian Vondendriesch, docs by me Report by Jeff Janes
2014-04-19 14:41:51 +02:00
if (pvalue != NULL && pvalue[0] != '\0')
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
{
/* Search for the param record */
for (option = options; option->keyword != NULL; option++)
{
if (strcmp(option->keyword, pname) == 0)
break;
}
/* Check for invalid connection option */
if (option->keyword == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
libpq_gettext("invalid connection option \"%s\"\n"),
pname);
PQconninfoFree(options);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
PQconninfoFree(dbname_options);
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
return NULL;
}
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
/*
Allow "dbname" from connection string to be overridden in PQconnectDBParams If the "dbname" attribute in PQconnectDBParams contained a connection string or URI (and expand_dbname = TRUE), the database name from the connection string could not be overridden by a subsequent "dbname" keyword in the array. That was not intentional; all other options can be overridden. Furthermore, any subsequent "dbname" caused the connection string from the first dbname value to be processed again, overriding any values for the same options that were given between the connection string and the second dbname option. In the passing, clarify in the docs that only the first dbname option in the array is parsed as a connection string. Alex Shulgin. Backpatch to all supported versions.
2014-11-25 16:12:07 +01:00
* If we are on the first dbname parameter, and we have a parsed
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
* connection string, copy those parameters across, overriding any
* existing previous settings.
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
*/
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
if (strcmp(pname, "dbname") == 0 && dbname_options)
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
{
PQconninfoOption *str_option;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
for (str_option = dbname_options; str_option->keyword != NULL; str_option++)
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
{
if (str_option->val != NULL)
{
int k;
for (k = 0; options[k].keyword; k++)
{
if (strcmp(options[k].keyword, str_option->keyword) == 0)
{
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(options[k].val);
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
options[k].val = strdup(str_option->val);
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
if (!options[k].val)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
PQconninfoFree(options);
PQconninfoFree(dbname_options);
return NULL;
}
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
break;
}
}
}
}
pgindent run for 9.5
2015-05-24 03:35:49 +02:00
Allow "dbname" from connection string to be overridden in PQconnectDBParams If the "dbname" attribute in PQconnectDBParams contained a connection string or URI (and expand_dbname = TRUE), the database name from the connection string could not be overridden by a subsequent "dbname" keyword in the array. That was not intentional; all other options can be overridden. Furthermore, any subsequent "dbname" caused the connection string from the first dbname value to be processed again, overriding any values for the same options that were given between the connection string and the second dbname option. In the passing, clarify in the docs that only the first dbname option in the array is parsed as a connection string. Alex Shulgin. Backpatch to all supported versions.
2014-11-25 16:12:07 +01:00
/*
* Forget the parsed connection string, so that any subsequent
* dbname parameters will not be expanded.
*/
PQconninfoFree(dbname_options);
dbname_options = NULL;
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
}
else
{
/*
* Store the value, overriding previous settings
*/
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(option->val);
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
option->val = strdup(pvalue);
if (!option->val)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
PQconninfoFree(options);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
PQconninfoFree(dbname_options);
Modify recently added PQconnectdbParams() with new argument, expand_dbname. If expand_dbname is non-zero and dbname contains an = sign, it is taken as a conninfo string in exactly the same way as if it had been passed to PQconnectdb. This is equivalent to the way PQsetdbLogin() works, allowing PQconnectdbParams() to be a complete alternative. Also improve the way the new function is called from psql and replace a previously missed call to PQsetdbLogin() in psql. Additionally use PQconnectdbParams() for pg_dump and friends, and the bin/scripts command line utilities such as vacuumdb, createdb, etc. Finally, update the documentation for the new parameter, as well as the nuances of precedence in cases where key words are repeated or duplicated in the conninfo string.
2010-02-05 04:09:05 +01:00
return NULL;
}
}
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
}
++i;
}
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
PQconninfoFree(dbname_options);
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
/*
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
* Add in defaults if the caller wants that.
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
*/
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
if (use_defaults)
{
if (!conninfo_add_defaults(options, errorMessage))
{
PQconninfoFree(options);
return NULL;
}
}
return options;
}
/*
* Add the default values for any unspecified options to the connection
* options array.
*
* Defaults are obtained from a service file, environment variables, etc.
*
Change TRUE/FALSE to true/false The lower case spellings are C and C++ standard and are used in most parts of the PostgreSQL sources. The upper case spellings are only used in some files/modules. So standardize on the standard spellings. The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so those are left as is when using those APIs. In code comments, we use the lower-case spelling for the C concepts and keep the upper-case spelling for the SQL concepts. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-08-16 06:22:32 +02:00
* Returns true if successful, otherwise false; errorMessage, if supplied,
libpq: change PQconndefaults() to ignore invalid service files Previously missing or invalid service files returned NULL. Also fix pg_upgrade to report "out of memory" for a null return from PQconndefaults(). Patch by Steve Singer, rewritten by me
2013-12-03 17:11:56 +01:00
* is filled in upon failure. Note that failure to locate a default value
* is not an error condition here --- we just leave the option's value as
* NULL.
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
*/
static bool
conninfo_add_defaults(PQconninfoOption *options, PQExpBuffer errorMessage)
{
PQconninfoOption *option;
char *tmp;
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
/*
* If there's a service spec, use it to obtain any not-explicitly-given
libpq: change PQconndefaults() to ignore invalid service files Previously missing or invalid service files returned NULL. Also fix pg_upgrade to report "out of memory" for a null return from PQconndefaults(). Patch by Steve Singer, rewritten by me
2013-12-03 17:11:56 +01:00
* parameters. Ignore error if no error message buffer is passed because
* there is no way to pass back the failure message.
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
*/
libpq: change PQconndefaults() to ignore invalid service files Previously missing or invalid service files returned NULL. Also fix pg_upgrade to report "out of memory" for a null return from PQconndefaults(). Patch by Steve Singer, rewritten by me
2013-12-03 17:11:56 +01:00
if (parseServiceInfo(options, errorMessage) != 0 && errorMessage)
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
return false;
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
/*
* Get the fallback resources for parameters not specified in the conninfo
* string nor the service.
*/
for (option = options; option->keyword != NULL; option++)
{
if (option->val != NULL)
continue; /* Value was in conninfo or service */
/*
* Try to get the environment variable fallback
*/
if (option->envvar != NULL)
{
if ((tmp = getenv(option->envvar)) != NULL)
{
option->val = strdup(tmp);
if (!option->val)
{
libpq: change PQconndefaults() to ignore invalid service files Previously missing or invalid service files returned NULL. Also fix pg_upgrade to report "out of memory" for a null return from PQconndefaults(). Patch by Steve Singer, rewritten by me
2013-12-03 17:11:56 +01:00
if (errorMessage)
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
return false;
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
}
continue;
}
}
Restore PGREQUIRESSL recognition in libpq. Commit 65c3bf19fd3e1f6a591618e92eb4c54d0b217564 moved handling of the, already then, deprecated requiressl parameter into conninfo_storeval(). The default PGREQUIRESSL environment variable was however lost in the change resulting in a potentially silent accept of a non-SSL connection even when set. Its documentation remained. Restore its implementation. Also amend the documentation to mark PGREQUIRESSL as deprecated for those not following the link to requiressl. Back-patch to 9.3, where commit 65c3bf1 first appeared. Behavior has been more complex when the user provides both deprecated and non-deprecated settings. Before commit 65c3bf1, libpq operated according to the first of these found: requiressl=1 PGREQUIRESSL=1 sslmode=* PGSSLMODE=* (Note requiressl=0 didn't override sslmode=*; it would only suppress PGREQUIRESSL=1 or a previous requiressl=1. PGREQUIRESSL=0 had no effect whatsoever.) Starting with commit 65c3bf1, libpq ignored PGREQUIRESSL, and order of precedence changed to this: last of requiressl=* or sslmode=* PGSSLMODE=* Starting now, adopt the following order of precedence: last of requiressl=* or sslmode=* PGSSLMODE=* PGREQUIRESSL=1 This retains the 65c3bf1 behavior for connection strings that contain both requiressl=* and sslmode=*. It retains the 65c3bf1 change that either connection string option overrides both environment variables. For the first time, PGSSLMODE has precedence over PGREQUIRESSL; this avoids reducing security of "PGREQUIRESSL=1 PGSSLMODE=verify-full" configurations originating under v9.3 and later. Daniel Gustafsson Security: CVE-2017-7485
2017-05-08 16:24:24 +02:00
/*
* Interpret the deprecated PGREQUIRESSL environment variable. Per
* tradition, translate values starting with "1" to sslmode=require,
* and ignore other values. Given both PGREQUIRESSL=1 and PGSSLMODE,
* PGSSLMODE takes precedence; the opposite was true before v9.3.
*/
if (strcmp(option->keyword, "sslmode") == 0)
{
const char *requiresslenv = getenv("PGREQUIRESSL");
if (requiresslenv != NULL && requiresslenv[0] == '1')
{
option->val = strdup("require");
if (!option->val)
{
if (errorMessage)
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Restore PGREQUIRESSL recognition in libpq. Commit 65c3bf19fd3e1f6a591618e92eb4c54d0b217564 moved handling of the, already then, deprecated requiressl parameter into conninfo_storeval(). The default PGREQUIRESSL environment variable was however lost in the change resulting in a potentially silent accept of a non-SSL connection even when set. Its documentation remained. Restore its implementation. Also amend the documentation to mark PGREQUIRESSL as deprecated for those not following the link to requiressl. Back-patch to 9.3, where commit 65c3bf1 first appeared. Behavior has been more complex when the user provides both deprecated and non-deprecated settings. Before commit 65c3bf1, libpq operated according to the first of these found: requiressl=1 PGREQUIRESSL=1 sslmode=* PGSSLMODE=* (Note requiressl=0 didn't override sslmode=*; it would only suppress PGREQUIRESSL=1 or a previous requiressl=1. PGREQUIRESSL=0 had no effect whatsoever.) Starting with commit 65c3bf1, libpq ignored PGREQUIRESSL, and order of precedence changed to this: last of requiressl=* or sslmode=* PGSSLMODE=* Starting now, adopt the following order of precedence: last of requiressl=* or sslmode=* PGSSLMODE=* PGREQUIRESSL=1 This retains the 65c3bf1 behavior for connection strings that contain both requiressl=* and sslmode=*. It retains the 65c3bf1 change that either connection string option overrides both environment variables. For the first time, PGSSLMODE has precedence over PGREQUIRESSL; this avoids reducing security of "PGREQUIRESSL=1 PGSSLMODE=verify-full" configurations originating under v9.3 and later. Daniel Gustafsson Security: CVE-2017-7485
2017-05-08 16:24:24 +02:00
return false;
}
continue;
}
}
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
/*
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
* No environment variable specified or the variable isn't set - try
* compiled-in default
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
*/
if (option->compiled != NULL)
{
option->val = strdup(option->compiled);
if (!option->val)
{
libpq: change PQconndefaults() to ignore invalid service files Previously missing or invalid service files returned NULL. Also fix pg_upgrade to report "out of memory" for a null return from PQconndefaults(). Patch by Steve Singer, rewritten by me
2013-12-03 17:11:56 +01:00
if (errorMessage)
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
return false;
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
}
continue;
}
/*
Fix libpq's behavior when /etc/passwd isn't readable. Some users run their applications in chroot environments that lack an /etc/passwd file. This means that the current UID's user name and home directory are not obtainable. libpq used to be all right with that, so long as the database role name to use was specified explicitly. But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by causing any failure of pg_fe_getauthname() to be treated as a hard error. In any case it did little to advance its nominal goal of causing errors in pg_fe_getauthname() to be reported better. So revert that and instead put some real error-reporting code in place. This requires changes to the APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had departed from the POSIX-specified API of getpwuid_r() in a way that made it impossible to distinguish actual lookup errors from "no such user". To allow such failures to be reported, while not failing if the caller supplies a role name, add a second call of pg_fe_getauthname() in connectOptions2(). This is a tad ugly, and could perhaps be avoided with some refactoring of PQsetdbLogin(), but I'll leave that idea for later. (Note that the complained-of misbehavior only occurs in PQsetdbLogin, not when using the PQconnect functions, because in the latter we will never bother to call pg_fe_getauthname() if the user gives a role name.) In passing also clean up the Windows-side usage of GetUserName(): the recommended buffer size is 257 bytes, the passed buffer length should be the buffer size not buffer size less 1, and any error is reported by GetLastError() not errno. Per report from Christoph Berg. Back-patch to 9.4 where the chroot failure case was introduced. The generally poor reporting of errors here is of very long standing, of course, but given the lack of field complaints about it we won't risk changing these APIs further back (even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
* Special handling for "user" option. Note that if pg_fe_getauthname
* fails, we just leave the value as NULL; there's no need for this to
* be an error condition if the caller provides a user name. The only
* reason we do this now at all is so that callers of PQconndefaults
* will see a correct default (barring error, of course).
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
*/
if (strcmp(option->keyword, "user") == 0)
{
Fix libpq's behavior when /etc/passwd isn't readable. Some users run their applications in chroot environments that lack an /etc/passwd file. This means that the current UID's user name and home directory are not obtainable. libpq used to be all right with that, so long as the database role name to use was specified explicitly. But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by causing any failure of pg_fe_getauthname() to be treated as a hard error. In any case it did little to advance its nominal goal of causing errors in pg_fe_getauthname() to be reported better. So revert that and instead put some real error-reporting code in place. This requires changes to the APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had departed from the POSIX-specified API of getpwuid_r() in a way that made it impossible to distinguish actual lookup errors from "no such user". To allow such failures to be reported, while not failing if the caller supplies a role name, add a second call of pg_fe_getauthname() in connectOptions2(). This is a tad ugly, and could perhaps be avoided with some refactoring of PQsetdbLogin(), but I'll leave that idea for later. (Note that the complained-of misbehavior only occurs in PQsetdbLogin, not when using the PQconnect functions, because in the latter we will never bother to call pg_fe_getauthname() if the user gives a role name.) In passing also clean up the Windows-side usage of GetUserName(): the recommended buffer size is 257 bytes, the passed buffer length should be the buffer size not buffer size less 1, and any error is reported by GetLastError() not errno. Per report from Christoph Berg. Back-patch to 9.4 where the chroot failure case was introduced. The generally poor reporting of errors here is of very long standing, of course, but given the lack of field complaints about it we won't risk changing these APIs further back (even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
option->val = pg_fe_getauthname(NULL);
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
continue;
}
}
Refactor to eliminate duplicate copies of conninfo default-finding code. Alex Shulgin, lightly edited by me
2012-03-22 17:08:34 +01:00
return true;
Introduce two new libpq connection functions, PQconnectdbParams and PQconnectStartParams. These are analogous to PQconnectdb and PQconnectStart respectively. They differ from the legacy functions in that they accept two NULL-terminated arrays, keywords and values, rather than conninfo strings. This avoids the need to build the conninfo string in cases where it might be inconvenient to do so. Includes documentation. Also modify psql to utilize PQconnectdbParams rather than PQsetdbLogin. This allows the new config parameter application_name to be set, which in turn is displayed in the pg_stat_activity view and included in CSV log entries. This will also ensure both new functions get regularly exercised. Patch by Guillaume Lelarge with review and minor adjustments by Joe Conway.
2010-01-28 07:28:26 +01:00
}
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
/*
* Subroutine for parse_connection_string
*
* Deal with a URI connection string.
*/
static PQconninfoOption *
conninfo_uri_parse(const char *uri, PQExpBuffer errorMessage,
bool use_defaults)
{
PQconninfoOption *options;
/* Make a working copy of PQconninfoOptions */
options = conninfo_init(errorMessage);
if (options == NULL)
return NULL;
if (!conninfo_uri_parse_options(options, uri, errorMessage))
{
PQconninfoFree(options);
return NULL;
}
/*
* Add in defaults if the caller wants that.
*/
if (use_defaults)
{
if (!conninfo_add_defaults(options, errorMessage))
{
PQconninfoFree(options);
return NULL;
}
}
return options;
}
/*
* conninfo_uri_parse_options
* Actual URI parser.
*
* If successful, returns true while the options array is filled with parsed
* options from the URI.
* If not successful, returns false and fills errorMessage accordingly.
*
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
* Parses the connection URI string in 'uri' according to the URI syntax (RFC
* 3986):
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
*
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
* postgresql://[user[:password]@][netloc][:port][/dbname][?param1=value1&...]
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
*
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
* where "netloc" is a hostname, an IPv4 address, or an IPv6 address surrounded
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
* by literal square brackets. As an extension, we also allow multiple
* netloc[:port] specifications, separated by commas:
*
* postgresql://[user[:password]@][netloc][:port][,...][/dbname][?param1=value1&...]
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
*
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
* Any of the URI parts might use percent-encoding (%xy).
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
*/
static bool
conninfo_uri_parse_options(PQconninfoOption *options, const char *uri,
PQExpBuffer errorMessage)
{
int prefix_len;
char *p;
Code review for commit 274bb2b3857cc987cfa21d14775cae9b0dababa5. Avoid memory leak in conninfo_uri_parse_options. Use the current host rather than the comma-separated list of host names when the host name is needed for GSS, SSPI, or SSL authentication. Document the way connect_timeout interacts with multiple host specifications. Takayuki Tsunakawa
2016-11-22 21:32:13 +01:00
char *buf = NULL;
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
char *start;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
char prevchar = '\0';
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
char *user = NULL;
char *host = NULL;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
bool retval = false;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
PQExpBufferData hostbuf;
PQExpBufferData portbuf;
initPQExpBuffer(&hostbuf);
initPQExpBuffer(&portbuf);
if (PQExpBufferDataBroken(hostbuf) || PQExpBufferDataBroken(portbuf))
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Code review for commit 274bb2b3857cc987cfa21d14775cae9b0dababa5. Avoid memory leak in conninfo_uri_parse_options. Use the current host rather than the comma-separated list of host names when the host name is needed for GSS, SSPI, or SSL authentication. Document the way connect_timeout interacts with multiple host specifications. Takayuki Tsunakawa
2016-11-22 21:32:13 +01:00
goto cleanup;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
}
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
/* need a modifiable copy of the input URI */
buf = strdup(uri);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
if (buf == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage,
libpq_gettext("out of memory\n"));
Code review for commit 274bb2b3857cc987cfa21d14775cae9b0dababa5. Avoid memory leak in conninfo_uri_parse_options. Use the current host rather than the comma-separated list of host names when the host name is needed for GSS, SSPI, or SSL authentication. Document the way connect_timeout interacts with multiple host specifications. Takayuki Tsunakawa
2016-11-22 21:32:13 +01:00
goto cleanup;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
}
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
start = buf;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
/* Skip the URI prefix */
Revert "psql: fix \connect with URIs and conninfo strings" This reverts commit fcef1617295c074f2684c887627184d2fc26ac04, about which both the buildfarm and my local machine are very unhappy.
2015-04-02 16:10:22 +02:00
prefix_len = uri_prefix_length(uri);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
if (prefix_len == 0)
{
/* Should never happen */
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
libpq_gettext("invalid URI propagated to internal parser routine: \"%s\"\n"),
uri);
goto cleanup;
}
start += prefix_len;
p = start;
/* Look ahead for possible user credentials designator */
while (*p && *p != '@' && *p != '/')
++p;
if (*p == '@')
{
/*
* Found username/password designator, so URI should be of the form
* "scheme://user[:password]@[netloc]".
*/
user = start;
p = user;
while (*p != ':' && *p != '@')
++p;
/* Save last char and cut off at end of user name */
prevchar = *p;
*p = '\0';
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
if (*user &&
!conninfo_storeval(options, "user", user,
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
errorMessage, false, true))
goto cleanup;
if (prevchar == ':')
{
const char *password = p + 1;
while (*p != '@')
++p;
*p = '\0';
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
if (*password &&
!conninfo_storeval(options, "password", password,
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
errorMessage, false, true))
goto cleanup;
}
/* Advance past end of parsed user name or password token */
++p;
}
else
{
/*
* No username/password designator found. Reset to start of URI.
*/
p = start;
}
/*
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
* There may be multiple netloc[:port] pairs, each separated from the next
* by a comma. When we initially enter this loop, "p" has been
* incremented past optional URI credential information at this point and
* now points at the "netloc" part of the URI. On subsequent loop
* iterations, "p" has been incremented past the comma separator and now
* points at the start of the next "netloc".
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
*/
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
for (;;)
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
{
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
/*
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
* Look for IPv6 address.
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
*/
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
if (*p == '[')
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
{
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
host = ++p;
while (*p && *p != ']')
++p;
if (!*p)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
libpq_gettext("end of string reached when looking for matching \"]\" in IPv6 host address in URI: \"%s\"\n"),
uri);
goto cleanup;
}
if (p == host)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
libpq_gettext("IPv6 host address may not be empty in URI: \"%s\"\n"),
uri);
goto cleanup;
}
/* Cut off the bracket and advance */
*(p++) = '\0';
/*
* The address may be followed by a port specifier or a slash or a
* query or a separator comma.
*/
if (*p && *p != ':' && *p != '/' && *p != '?' && *p != ',')
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
libpq_gettext("unexpected character \"%c\" at position %d in URI (expected \":\" or \"/\"): \"%s\"\n"),
*p, (int) (p - buf + 1), uri);
goto cleanup;
}
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
}
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
else
{
/* not an IPv6 address: DNS-named or IPv4 netloc */
host = p;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
/*
* Look for port specifier (colon) or end of host specifier
* (slash) or query (question mark) or host separator (comma).
*/
while (*p && *p != ':' && *p != '/' && *p != '?' && *p != ',')
++p;
}
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
/* Save the hostname terminator before we null it */
prevchar = *p;
*p = '\0';
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
appendPQExpBufferStr(&hostbuf, host);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
if (prevchar == ':')
{
const char *port = ++p; /* advance past host terminator */
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
while (*p && *p != '/' && *p != '?' && *p != ',')
++p;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
prevchar = *p;
*p = '\0';
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
appendPQExpBufferStr(&portbuf, port);
}
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
if (prevchar != ',')
break;
++p; /* advance past comma separator */
Fix up some misusage of appendStringInfo() and friends Change to appendStringInfoChar() or appendStringInfoString() where those can be used. Author: David Rowley <david.rowley@2ndquadrant.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
2017-08-16 05:34:39 +02:00
appendPQExpBufferChar(&hostbuf, ',');
appendPQExpBufferChar(&portbuf, ',');
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
}
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
/* Save final values for host and port. */
if (PQExpBufferDataBroken(hostbuf) || PQExpBufferDataBroken(portbuf))
goto cleanup;
if (hostbuf.data[0] &&
!conninfo_storeval(options, "host", hostbuf.data,
errorMessage, false, true))
goto cleanup;
if (portbuf.data[0] &&
!conninfo_storeval(options, "port", portbuf.data,
errorMessage, false, true))
goto cleanup;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
if (prevchar && prevchar != '?')
{
const char *dbname = ++p; /* advance past host terminator */
/* Look for query parameters */
while (*p && *p != '?')
++p;
prevchar = *p;
*p = '\0';
/*
* Avoid setting dbname to an empty string, as it forces the default
* value (username) and ignores $PGDATABASE, as opposed to not setting
* it at all.
*/
if (*dbname &&
!conninfo_storeval(options, "dbname", dbname,
errorMessage, false, true))
goto cleanup;
}
if (prevchar)
{
++p; /* advance past terminator */
if (!conninfo_uri_parse_params(p, options, errorMessage))
goto cleanup;
}
/* everything parsed okay */
retval = true;
cleanup:
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
termPQExpBuffer(&hostbuf);
termPQExpBuffer(&portbuf);
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(buf);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
return retval;
}
/*
* Connection URI parameters parser routine
*
* If successful, returns true while connOptions is filled with parsed
* parameters. Otherwise, returns false and fills errorMessage appropriately.
*
* Destructively modifies 'params' buffer.
*/
static bool
conninfo_uri_parse_params(char *params,
PQconninfoOption *connOptions,
PQExpBuffer errorMessage)
{
while (*params)
{
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
char *keyword = params;
char *value = NULL;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
char *p = params;
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
bool malloced = false;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
int oldmsglen;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
/*
* Scan the params string for '=' and '&', marking the end of keyword
* and value respectively.
*/
for (;;)
{
if (*p == '=')
{
/* Was there '=' already? */
if (value != NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Assorted message style improvements
2012-07-02 20:12:46 +02:00
libpq_gettext("extra key/value separator \"=\" in URI query parameter: \"%s\"\n"),
Minor code beautification in conninfo_uri_parse_params(). Reading this made me itch, so clean the logic a bit.
2015-02-21 19:27:12 +01:00
keyword);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
return false;
}
/* Cut off keyword, advance to value */
Minor code beautification in conninfo_uri_parse_params(). Reading this made me itch, so clean the logic a bit.
2015-02-21 19:27:12 +01:00
*p++ = '\0';
value = p;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
}
else if (*p == '&' || *p == '\0')
{
Minor code beautification in conninfo_uri_parse_params(). Reading this made me itch, so clean the logic a bit.
2015-02-21 19:27:12 +01:00
/*
* If not at the end, cut off value and advance; leave p
* pointing to start of the next parameter, if any.
*/
if (*p != '\0')
*p++ = '\0';
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
/* Was there '=' at all? */
if (value == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Assorted message style improvements
2012-07-02 20:12:46 +02:00
libpq_gettext("missing key/value separator \"=\" in URI query parameter: \"%s\"\n"),
Minor code beautification in conninfo_uri_parse_params(). Reading this made me itch, so clean the logic a bit.
2015-02-21 19:27:12 +01:00
keyword);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
return false;
}
Minor code beautification in conninfo_uri_parse_params(). Reading this made me itch, so clean the logic a bit.
2015-02-21 19:27:12 +01:00
/* Got keyword and value, go process them. */
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
break;
}
Fix misparsing of empty value in conninfo_uri_parse_params(). After finding an "=" character, the pointer was advanced twice when it should only advance once. This is harmless as long as the value after "=" has at least one character; but if it doesn't, we'd miss the terminator character and include too much in the value. In principle this could lead to reading off the end of memory. It does not seem worth treating as a security issue though, because it would happen on client side, and besides client logic that's taking conninfo strings from untrusted sources has much worse security problems than this. Report and patch received off-list from Thomas Fanghaenel. Back-patch to 9.2 where the faulty code was introduced.
2015-02-21 18:59:25 +01:00
else
++p; /* Advance over all other bytes. */
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
}
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
keyword = conninfo_uri_decode(keyword, errorMessage);
if (keyword == NULL)
{
/* conninfo_uri_decode already set an error message */
return false;
}
value = conninfo_uri_decode(value, errorMessage);
if (value == NULL)
{
/* conninfo_uri_decode already set an error message */
free(keyword);
return false;
}
malloced = true;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
/*
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
* Special keyword handling for improved JDBC compatibility.
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
*/
if (strcmp(keyword, "ssl") == 0 &&
strcmp(value, "true") == 0)
{
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
free(keyword);
free(value);
malloced = false;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
keyword = "sslmode";
value = "require";
}
/*
* Store the value if the corresponding option exists; ignore
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
* otherwise. At this point both keyword and value are not
* URI-encoded.
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
*/
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
oldmsglen = errorMessage->len;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
if (!conninfo_storeval(connOptions, keyword, value,
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
errorMessage, true, false))
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
{
Minor code beautification in conninfo_uri_parse_params(). Reading this made me itch, so clean the logic a bit.
2015-02-21 19:27:12 +01:00
/* Insert generic message if conninfo_storeval didn't give one. */
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
if (errorMessage->len == oldmsglen)
appendPQExpBuffer(errorMessage,
Minor code beautification in conninfo_uri_parse_params(). Reading this made me itch, so clean the logic a bit.
2015-02-21 19:27:12 +01:00
libpq_gettext("invalid URI query parameter: \"%s\"\n"),
keyword);
/* And fail. */
libpq: Fix memory leak in URI parser When an invalid query parameter is reported, some memory leaks. found by Coverity
2012-08-24 04:33:04 +02:00
if (malloced)
{
free(keyword);
free(value);
}
When using libpq URI syntax, error out on invalid parameter names. Dan Farina
2012-06-08 14:46:39 +02:00
return false;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
}
Minor code beautification in conninfo_uri_parse_params(). Reading this made me itch, so clean the logic a bit.
2015-02-21 19:27:12 +01:00
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
if (malloced)
{
free(keyword);
free(value);
}
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
Minor code beautification in conninfo_uri_parse_params(). Reading this made me itch, so clean the logic a bit.
2015-02-21 19:27:12 +01:00
/* Proceed to next key=value pair, if any */
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
params = p;
}
return true;
}
/*
* Connection URI decoder routine
*
* If successful, returns the malloc'd decoded string.
* If not successful, returns NULL and fills errorMessage accordingly.
*
* The string is decoded by replacing any percent-encoded tokens with
* corresponding characters, while preserving any non-encoded characters. A
* percent-encoded token is a character triplet: a percent sign, followed by a
* pair of hexadecimal digits (0-9A-F), where lower- and upper-case letters are
* treated identically.
*/
Reverse out const to libpq interface from D'Arcy.
1999-02-05 05:25:55 +01:00
static char *
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
conninfo_uri_decode(const char *str, PQExpBuffer errorMessage)
{
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
char *buf;
char *p;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
const char *q = str;
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
buf = malloc(strlen(str) + 1);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
if (buf == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage, libpq_gettext("out of memory\n"));
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
return NULL;
}
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
p = buf;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
for (;;)
{
if (*q != '%')
{
/* copy and check for NUL terminator */
if (!(*(p++) = *(q++)))
break;
}
else
{
int hi;
int lo;
int c;
++q; /* skip the percent sign itself */
/*
* Possible EOL will be caught by the first call to
* get_hexdigit(), so we never dereference an invalid q pointer.
*/
if (!(get_hexdigit(*q++, &hi) && get_hexdigit(*q++, &lo)))
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Replace libpq's "row processor" API with a "single row" mode. After taking awhile to digest the row-processor feature that was added to libpq in commit 92785dac2ee7026948962cd61c4cd84a2d052772, we've concluded it is over-complicated and too hard to use. Leave the core infrastructure changes in place (that is, there's still a row processor function inside libpq), but remove the exposed API pieces, and instead provide a "single row" mode switch that causes PQgetResult to return one row at a time in separate PGresult objects. This approach incurs more overhead than proper use of a row processor callback would, since construction of a PGresult per row adds extra cycles. However, it is far easier to use and harder to break. The single-row mode still affords applications the primary benefit that the row processor API was meant to provide, namely not having to accumulate large result sets in memory before processing them. Preliminary testing suggests that we can probably buy back most of the extra cycles by micro-optimizing construction of the extra results, but that task will be left for another day. Marko Kreen
2012-08-02 19:10:30 +02:00
libpq_gettext("invalid percent-encoded token: \"%s\"\n"),
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
str);
free(buf);
return NULL;
}
c = (hi << 4) | lo;
if (c == 0)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Assorted message style improvements
2012-07-02 20:12:46 +02:00
libpq_gettext("forbidden value %%00 in percent-encoded value: \"%s\"\n"),
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
str);
free(buf);
return NULL;
}
*(p++) = c;
}
}
return buf;
}
/*
* Convert hexadecimal digit character to its integer value.
*
* If successful, returns true and value is filled with digit's base 16 value.
* If not successful, returns false.
*
* Lower- and upper-case letters in the range A-F are treated identically.
*/
static bool
get_hexdigit(char digit, int *value)
{
if ('0' <= digit && digit <= '9')
*value = digit - '0';
else if ('A' <= digit && digit <= 'F')
*value = digit - 'A' + 10;
else if ('a' <= digit && digit <= 'f')
*value = digit - 'a' + 10;
else
return false;
return true;
}
/*
* Find an option value corresponding to the keyword in the connOptions array.
*
* If successful, returns a pointer to the corresponding option's value.
* If not successful, returns NULL.
*/
static const char *
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
conninfo_getval(PQconninfoOption *connOptions,
const char *keyword)
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{
PQconninfoOption *option;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
option = conninfo_find(connOptions, keyword);
return option ? option->val : NULL;
}
/*
* Store a (new) value for an option corresponding to the keyword in
* connOptions array.
*
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
* If uri_decode is true, the value is URI-decoded. The keyword is always
* assumed to be non URI-encoded.
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
*
* If successful, returns a pointer to the corresponding PQconninfoOption,
* which value is replaced with a strdup'd copy of the passed value string.
* The existing value for the option is free'd before replacing, if any.
*
* If not successful, returns NULL and fills errorMessage accordingly.
* However, if the reason of failure is an invalid keyword being passed and
Change TRUE/FALSE to true/false The lower case spellings are C and C++ standard and are used in most parts of the PostgreSQL sources. The upper case spellings are only used in some files/modules. So standardize on the standard spellings. The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so those are left as is when using those APIs. In code comments, we use the lower-case spelling for the C concepts and keep the upper-case spelling for the SQL concepts. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-08-16 06:22:32 +02:00
* ignoreMissing is true, errorMessage will be left untouched.
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
*/
static PQconninfoOption *
conninfo_storeval(PQconninfoOption *connOptions,
const char *keyword, const char *value,
PQExpBuffer errorMessage, bool ignoreMissing,
bool uri_decode)
{
PQconninfoOption *option;
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
char *value_copy;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
/*
* For backwards compatibility, requiressl=1 gets translated to
* sslmode=require, and requiressl=0 gets translated to sslmode=prefer
* (which is the default for sslmode).
*/
if (strcmp(keyword, "requiressl") == 0)
{
keyword = "sslmode";
if (value[0] == '1')
value = "require";
else
value = "prefer";
}
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
option = conninfo_find(connOptions, keyword);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
if (option == NULL)
{
if (!ignoreMissing)
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBuffer(errorMessage,
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
libpq_gettext("invalid connection option \"%s\"\n"),
keyword);
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
return NULL;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
}
if (uri_decode)
{
value_copy = conninfo_uri_decode(value, errorMessage);
if (value_copy == NULL)
/* conninfo_uri_decode already set an error message */
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
return NULL;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
}
else
{
value_copy = strdup(value);
if (value_copy == NULL)
{
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
appendPQExpBufferStr(errorMessage, libpq_gettext("out of memory\n"));
libpq: URI parsing fixes Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
2012-05-28 21:44:34 +02:00
return NULL;
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
}
}
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
free(option->val);
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
option->val = value_copy;
return option;
}
/*
* Find a PQconninfoOption option corresponding to the keyword in the
* connOptions array.
*
* If successful, returns a pointer to the corresponding PQconninfoOption
* structure.
* If not successful, returns NULL.
*/
static PQconninfoOption *
conninfo_find(PQconninfoOption *connOptions, const char *keyword)
{
PQconninfoOption *option;
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
for (option = connOptions; option->keyword != NULL; option++)
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
if (strcmp(option->keyword, keyword) == 0)
Accept postgres:// URIs in libpq connection functions postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
2012-04-11 08:59:32 +02:00
return option;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
}
return NULL;
}
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
/*
* Return the connection options used for the connection
*/
PQconninfoOption *
PQconninfo(PGconn *conn)
{
PQExpBufferData errorBuf;
PQconninfoOption *connOptions;
if (conn == NULL)
return NULL;
In libpq, always append new error messages to conn->errorMessage. Previously, we had an undisciplined mish-mash of printfPQExpBuffer and appendPQExpBuffer calls to report errors within libpq. This commit establishes a uniform rule that appendPQExpBuffer[Str] should be used. conn->errorMessage is reset only at the start of an application request, and then accumulates messages till we're done. We can remove no less than three different ad-hoc mechanisms that were used to get the effect of concatenation of error messages within a sequence of operations. Although this makes things quite a bit cleaner conceptually, the main reason to do it is to make the world safer for the multiple-target-host feature that was added awhile back. Previously, there were many cases in which an error occurring during an individual host connection attempt would wipe out the record of what had happened during previous attempts. (The reporting is still inadequate, in that it can be hard to tell which host got the failure, but that seems like a matter for a separate commit.) Currently, lo_import and lo_export contain exceptions to the "never use printfPQExpBuffer" rule. If we changed them, we'd risk reporting an incidental lo_close failure before the actual read or write failure, which would be confusing, not least because lo_close happened after the main failure. We could improve this by inventing an internal version of lo_close that doesn't reset the errorMessage; but we'd also need a version of PQfn() that does that, and it didn't quite seem worth the trouble for now. Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
/*
* We don't actually report any errors here, but callees want a buffer,
* and we prefer not to trash the conn's errorMessage.
*/
Add libpq function PQconninfo() This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
2012-11-30 07:09:18 +01:00
initPQExpBuffer(&errorBuf);
if (PQExpBufferDataBroken(errorBuf))
return NULL; /* out of memory already :-( */
connOptions = conninfo_init(&errorBuf);
if (connOptions != NULL)
{
const internalPQconninfoOption *option;
for (option = PQconninfoOptions; option->keyword; option++)
{
char **connmember;
if (option->connofs < 0)
continue;
connmember = (char **) ((char *) conn + option->connofs);
if (*connmember)
conninfo_storeval(connOptions, option->keyword, *connmember,
&errorBuf, true, false);
}
}
termPQExpBuffer(&errorBuf);
return connOptions;
}
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
void
PQconninfoFree(PQconninfoOption *connOptions)
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
if (connOptions == NULL)
return;
Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
2022-06-16 21:50:56 +02:00
for (PQconninfoOption *option = connOptions; option->keyword != NULL; option++)
free(option->val);
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
free(connOptions);
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
}
Defend against possibility that SSL error reporting mechanism returns a NULL pointer. Per report from Stephen Pillinger 8-Nov-01.
2001-11-11 03:09:05 +01:00
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/* =========== accessor functions for PGconn ========= */
Fixed psql double quoting of SQL ids Fixed libpq printing functions
2000-02-08 00:10:11 +01:00
char *
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
PQdb(const PGconn *conn)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
fixes for several potential null pointer dereferences submitted by: Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
1996-07-12 06:53:59 +02:00
if (!conn)
More janitorial work: remove the explicit casting of NULL literals to a pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
2004-01-07 19:56:30 +01:00
return NULL;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
return conn->dbName;
}
Fixed psql double quoting of SQL ids Fixed libpq printing functions
2000-02-08 00:10:11 +01:00
char *
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
PQuser(const PGconn *conn)
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
{
if (!conn)
More janitorial work: remove the explicit casting of NULL literals to a pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
2004-01-07 19:56:30 +01:00
return NULL;
Added in PQconnectdb() function Submitted by: wieck@sapserv.debis.de (Jan Wieck)
1996-11-09 11:39:54 +01:00
return conn->pguser;
}
Fixed psql double quoting of SQL ids Fixed libpq printing functions
2000-02-08 00:10:11 +01:00
char *
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
PQpass(const PGconn *conn)
Attached is a patch to remove the definitions of libpq's internal structs from libpq-fe.h, as we previously discussed. There turned out to be sloppy coding practices in more places than I had realized :-(, but all in all I think it was a well-worth-while exercise. I ended up adding several routines to libpq's API in order to respond to application requirements that were exposed by this work. I owe the docs crew updates for libpq.sgml to describe these changes. I'm way too tired to work on the docs tonight, however. This is the last major change I intend to submit for 6.4. I do want to see if I can make libpgtcl work with Tcl 8.0 before we go final, but hopefully that will be a minor bug fix.
1998-09-03 04:10:56 +02:00
{
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
char *password = NULL;
Attached is a patch to remove the definitions of libpq's internal structs from libpq-fe.h, as we previously discussed. There turned out to be sloppy coding practices in more places than I had realized :-(, but all in all I think it was a well-worth-while exercise. I ended up adding several routines to libpq's API in order to respond to application requirements that were exposed by this work. I owe the docs crew updates for libpq.sgml to describe these changes. I'm way too tired to work on the docs tonight, however. This is the last major change I intend to submit for 6.4. I do want to see if I can make libpgtcl work with Tcl 8.0 before we go final, but hopefully that will be a minor bug fix.
1998-09-03 04:10:56 +02:00
if (!conn)
More janitorial work: remove the explicit casting of NULL literals to a pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
2004-01-07 19:56:30 +01:00
return NULL;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
if (conn->connhost != NULL)
password = conn->connhost[conn->whichhost].password;
if (password == NULL)
password = conn->pgpass;
Allow password file name to be specified as a libpq connection parameter. Formerly an alternate password file could only be selected via the environment variable PGPASSFILE; now it can also be selected via a new connection parameter "passfile", corresponding to the conventions for most other connection parameters. There was some concern about this creating a security weakness, but it was agreed that that argument was pretty thin, and there are clear use-cases for handling password files this way. Julian Markwort, reviewed by Fabien Coelho, some adjustments by me Discussion: https://postgr.es/m/a4b4f4f1-7b58-a0e8-5268-5f7db8e8ccaa@uni-muenster.de
2017-01-24 23:06:21 +01:00
/* Historically we've returned "" not NULL for no password specified */
if (password == NULL)
password = "";
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
return password;
Attached is a patch to remove the definitions of libpq's internal structs from libpq-fe.h, as we previously discussed. There turned out to be sloppy coding practices in more places than I had realized :-(, but all in all I think it was a well-worth-while exercise. I ended up adding several routines to libpq's API in order to respond to application requirements that were exposed by this work. I owe the docs crew updates for libpq.sgml to describe these changes. I'm way too tired to work on the docs tonight, however. This is the last major change I intend to submit for 6.4. I do want to see if I can make libpgtcl work with Tcl 8.0 before we go final, but hopefully that will be a minor bug fix.
1998-09-03 04:10:56 +02:00
}
Fixed psql double quoting of SQL ids Fixed libpq printing functions
2000-02-08 00:10:11 +01:00
char *
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
PQhost(const PGconn *conn)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
fixes for several potential null pointer dereferences submitted by: Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
1996-07-12 06:53:59 +02:00
if (!conn)
More janitorial work: remove the explicit casting of NULL literals to a pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
2004-01-07 19:56:30 +01:00
return NULL;
libpq: PQhost to return active connected host or hostaddr Previously, PQhost didn't return the connected host details when the connection type was CHT_HOST_ADDRESS (i.e., via hostaddr). Instead, it returned the complete host connection parameter (which could contain multiple hosts) or the default host details, which was confusing and arguably incorrect. Change this to return the actually connected host or hostaddr irrespective of the connection type. When hostaddr but no host was specified, hostaddr is now returned. Never return the original host connection parameter, and document that PQhost cannot be relied on before the connection is established. PQport is similarly changed to always return the active connection port and never the original connection parameter. Author: Hari Babu <kommi.haribabu@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>
2018-03-27 18:31:34 +02:00
if (conn->connhost != NULL)
Fix bugs in PQhost(). In the platform that doesn't support Unix-domain socket, when neither host nor hostaddr are specified, the default host 'localhost' is used to connect to the server and PQhost() must return that, but it didn't. This patch fixes PQhost() so that it returns the default host in that case. Also this patch fixes PQhost() so that it doesn't return Unix-domain socket directory path in the platform that doesn't support Unix-domain socket. Back-patch to all supported versions.
2014-01-23 14:48:12 +01:00
{
Tweak libpq's PQhost, PQhostaddr, and psql's \connect Fixes some problems introduced by 6e5f8d489acc: * When reusing conninfo data from the previous connection in \connect, the host address should only be reused if it was specified as hostaddr; if it wasn't, then 'host' is resolved afresh. We were reusing the same IP address, which ignores a possible DNS change as well as any other addresses that the name resolves to than the one that was used in the original connection. * PQhost, PQhostaddr: Don't present user-specified hostaddr when we have an inet_net_ntop-produced equivalent address. The latter has been put in canonical format, which is cleaner (so it produces "127.0.0.1" when given "host=2130706433", for example). * Document the hostaddr-reusing aspect of \connect. * Fix some code comments Author: Fabien Coelho Reported-by: Noah Misch Discussion: https://postgr.es/m/20190527203713.GA58392@gust.leadboat.com
2019-06-15 00:02:26 +02:00
/*
* Return the verbatim host value provided by user, or hostaddr in its
* lack.
*/
libpq: PQhost to return active connected host or hostaddr Previously, PQhost didn't return the connected host details when the connection type was CHT_HOST_ADDRESS (i.e., via hostaddr). Instead, it returned the complete host connection parameter (which could contain multiple hosts) or the default host details, which was confusing and arguably incorrect. Change this to return the actually connected host or hostaddr irrespective of the connection type. When hostaddr but no host was specified, hostaddr is now returned. Never return the original host connection parameter, and document that PQhost cannot be relied on before the connection is established. PQport is similarly changed to always return the active connection port and never the original connection parameter. Author: Hari Babu <kommi.haribabu@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>
2018-03-27 18:31:34 +02:00
if (conn->connhost[conn->whichhost].host != NULL &&
conn->connhost[conn->whichhost].host[0] != '\0')
return conn->connhost[conn->whichhost].host;
else if (conn->connhost[conn->whichhost].hostaddr != NULL &&
conn->connhost[conn->whichhost].hostaddr[0] != '\0')
return conn->connhost[conn->whichhost].hostaddr;
Fix bugs in PQhost(). In the platform that doesn't support Unix-domain socket, when neither host nor hostaddr are specified, the default host 'localhost' is used to connect to the server and PQhost() must return that, but it didn't. This patch fixes PQhost() so that it returns the default host in that case. Also this patch fixes PQhost() so that it doesn't return Unix-domain socket directory path in the platform that doesn't support Unix-domain socket. Back-patch to all supported versions.
2014-01-23 14:48:12 +01:00
}
libpq: PQhost to return active connected host or hostaddr Previously, PQhost didn't return the connected host details when the connection type was CHT_HOST_ADDRESS (i.e., via hostaddr). Instead, it returned the complete host connection parameter (which could contain multiple hosts) or the default host details, which was confusing and arguably incorrect. Change this to return the actually connected host or hostaddr irrespective of the connection type. When hostaddr but no host was specified, hostaddr is now returned. Never return the original host connection parameter, and document that PQhost cannot be relied on before the connection is established. PQport is similarly changed to always return the active connection port and never the original connection parameter. Author: Hari Babu <kommi.haribabu@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>
2018-03-27 18:31:34 +02:00
return "";
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
psql: Show IP address in \conninfo When hostaddr is given, the actual IP address that psql is connected to can be totally unexpected for the given host. The more verbose output we now generate makes things clearer. Since the "host" and "hostaddr" parts of the conninfo could come from different sources (say, one of them is in the service specification or a URI-style conninfo and the other is not), this is not as silly as it may first appear. This is also definitely useful if the hostname resolves to multiple addresses. Author: Fabien Coelho Reviewed-by: Pavel Stehule, Arthur Zakirov Discussion: https://postgr.es/m/alpine.DEB.2.21.1810261532380.27686@lancre https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre
2018-11-19 18:34:12 +01:00
char *
PQhostaddr(const PGconn *conn)
{
if (!conn)
return NULL;
Tweak libpq's PQhost, PQhostaddr, and psql's \connect Fixes some problems introduced by 6e5f8d489acc: * When reusing conninfo data from the previous connection in \connect, the host address should only be reused if it was specified as hostaddr; if it wasn't, then 'host' is resolved afresh. We were reusing the same IP address, which ignores a possible DNS change as well as any other addresses that the name resolves to than the one that was used in the original connection. * PQhost, PQhostaddr: Don't present user-specified hostaddr when we have an inet_net_ntop-produced equivalent address. The latter has been put in canonical format, which is cleaner (so it produces "127.0.0.1" when given "host=2130706433", for example). * Document the hostaddr-reusing aspect of \connect. * Fix some code comments Author: Fabien Coelho Reported-by: Noah Misch Discussion: https://postgr.es/m/20190527203713.GA58392@gust.leadboat.com
2019-06-15 00:02:26 +02:00
/* Return the parsed IP address */
if (conn->connhost != NULL && conn->connip != NULL)
return conn->connip;
psql: Show IP address in \conninfo When hostaddr is given, the actual IP address that psql is connected to can be totally unexpected for the given host. The more verbose output we now generate makes things clearer. Since the "host" and "hostaddr" parts of the conninfo could come from different sources (say, one of them is in the service specification or a URI-style conninfo and the other is not), this is not as silly as it may first appear. This is also definitely useful if the hostname resolves to multiple addresses. Author: Fabien Coelho Reviewed-by: Pavel Stehule, Arthur Zakirov Discussion: https://postgr.es/m/alpine.DEB.2.21.1810261532380.27686@lancre https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre
2018-11-19 18:34:12 +01:00
return "";
}
Fixed psql double quoting of SQL ids Fixed libpq printing functions
2000-02-08 00:10:11 +01:00
char *
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
PQport(const PGconn *conn)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
fixes for several potential null pointer dereferences submitted by: Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
1996-07-12 06:53:59 +02:00
if (!conn)
More janitorial work: remove the explicit casting of NULL literals to a pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
2004-01-07 19:56:30 +01:00
return NULL;
libpq: PQhost to return active connected host or hostaddr Previously, PQhost didn't return the connected host details when the connection type was CHT_HOST_ADDRESS (i.e., via hostaddr). Instead, it returned the complete host connection parameter (which could contain multiple hosts) or the default host details, which was confusing and arguably incorrect. Change this to return the actually connected host or hostaddr irrespective of the connection type. When hostaddr but no host was specified, hostaddr is now returned. Never return the original host connection parameter, and document that PQhost cannot be relied on before the connection is established. PQport is similarly changed to always return the active connection port and never the original connection parameter. Author: Hari Babu <kommi.haribabu@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>
2018-03-27 18:31:34 +02:00
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
if (conn->connhost != NULL)
return conn->connhost[conn->whichhost].port;
libpq: PQhost to return active connected host or hostaddr Previously, PQhost didn't return the connected host details when the connection type was CHT_HOST_ADDRESS (i.e., via hostaddr). Instead, it returned the complete host connection parameter (which could contain multiple hosts) or the default host details, which was confusing and arguably incorrect. Change this to return the actually connected host or hostaddr irrespective of the connection type. When hostaddr but no host was specified, hostaddr is now returned. Never return the original host connection parameter, and document that PQhost cannot be relied on before the connection is established. PQport is similarly changed to always return the active connection port and never the original connection parameter. Author: Hari Babu <kommi.haribabu@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>
2018-03-27 18:31:34 +02:00
return "";
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
libpq: Remove deprecated connection parameters authtype and tty The authtype parameter was deprecated and made inactive in commit d5bbe2aca55bc8, but the environment variable was left defined and thus tested with a getenv call even though the value is of no use. Also, if it would exist it would be copied but never freed as the cleanup code had been removed. tty was deprecated in commit cb7fb3ca958ec8bd5a14e7 but most of the infrastructure around it remained in place. Author: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/DDDF36F3-582A-4C02-8598-9B464CC42B34@yesql.se
2021-03-09 15:01:22 +01:00
/*
* No longer does anything, but the function remains for API backwards
* compatibility.
*/
Fixed psql double quoting of SQL ids Fixed libpq printing functions
2000-02-08 00:10:11 +01:00
char *
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
PQtty(const PGconn *conn)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
fixes for several potential null pointer dereferences submitted by: Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
1996-07-12 06:53:59 +02:00
if (!conn)
More janitorial work: remove the explicit casting of NULL literals to a pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
2004-01-07 19:56:30 +01:00
return NULL;
libpq: Remove deprecated connection parameters authtype and tty The authtype parameter was deprecated and made inactive in commit d5bbe2aca55bc8, but the environment variable was left defined and thus tested with a getenv call even though the value is of no use. Also, if it would exist it would be copied but never freed as the cleanup code had been removed. tty was deprecated in commit cb7fb3ca958ec8bd5a14e7 but most of the infrastructure around it remained in place. Author: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/DDDF36F3-582A-4C02-8598-9B464CC42B34@yesql.se
2021-03-09 15:01:22 +01:00
return "";
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Fixed psql double quoting of SQL ids Fixed libpq printing functions
2000-02-08 00:10:11 +01:00
char *
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
PQoptions(const PGconn *conn)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
fixes for several potential null pointer dereferences submitted by: Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
1996-07-12 06:53:59 +02:00
if (!conn)
More janitorial work: remove the explicit casting of NULL literals to a pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
2004-01-07 19:56:30 +01:00
return NULL;
Attached is a patch to remove the definitions of libpq's internal structs from libpq-fe.h, as we previously discussed. There turned out to be sloppy coding practices in more places than I had realized :-(, but all in all I think it was a well-worth-while exercise. I ended up adding several routines to libpq's API in order to respond to application requirements that were exposed by this work. I owe the docs crew updates for libpq.sgml to describe these changes. I'm way too tired to work on the docs tonight, however. This is the last major change I intend to submit for 6.4. I do want to see if I can make libpgtcl work with Tcl 8.0 before we go final, but hopefully that will be a minor bug fix.
1998-09-03 04:10:56 +02:00
return conn->pgoptions;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
ConnStatusType
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
PQstatus(const PGconn *conn)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
fixes for several potential null pointer dereferences submitted by: Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
1996-07-12 06:53:59 +02:00
if (!conn)
return CONNECTION_BAD;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
return conn->status;
}
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
PGTransactionStatusType
PQtransactionStatus(const PGconn *conn)
{
if (!conn || conn->status != CONNECTION_OK)
return PQTRANS_UNKNOWN;
if (conn->asyncStatus != PGASYNC_IDLE)
return PQTRANS_ACTIVE;
return conn->xactStatus;
}
const char *
PQparameterStatus(const PGconn *conn, const char *paramName)
{
const pgParameterStatus *pstatus;
if (!conn || !paramName)
return NULL;
for (pstatus = conn->pstatus; pstatus != NULL; pstatus = pstatus->next)
{
if (strcmp(pstatus->name, paramName) == 0)
return pstatus->value;
}
return NULL;
}
int
PQprotocolVersion(const PGconn *conn)
{
if (!conn)
return 0;
if (conn->status == CONNECTION_BAD)
return 0;
return PG_PROTOCOL_MAJOR(conn->pversion);
}
Add PQserverVersion() to libpq to provide more-convenient access to the server version number. This commit also removes bogus DOS line endings from libpqddll.def. Greg Sabino Mullane
2004-08-11 20:06:01 +02:00
int
PQserverVersion(const PGconn *conn)
{
if (!conn)
return 0;
if (conn->status == CONNECTION_BAD)
return 0;
return conn->sversion;
}
Fixed psql double quoting of SQL ids Fixed libpq printing functions
2000-02-08 00:10:11 +01:00
char *
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
PQerrorMessage(const PGconn *conn)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
fixes for several potential null pointer dereferences submitted by: Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
1996-07-12 06:53:59 +02:00
if (!conn)
NLS for libpq. Clean up the message formats and change the documentation accordingly.
2001-07-15 15:45:04 +02:00
return libpq_gettext("connection pointer is NULL\n");
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
Improve libpq's handling of OOM during error message construction. Commit ffa2e4670 changed libpq so that multiple error reports occurring during one operation (a connection attempt or query) are accumulated in conn->errorMessage, where before new ones usually replaced any prior error. At least in theory, that makes us more vulnerable to running out of memory for the errorMessage buffer. If it did happen, the user would be left with just an empty-string error report, which is pretty unhelpful. We can improve this by relying on pqexpbuffer.c's existing "broken buffer" convention to track whether we've hit OOM for the current operation's error string, and then substituting a constant "out of memory" string in the small number of places where the errorMessage is read out. While at it, apply the same method to similar OOM cases in pqInternalNotice and pqGetErrorNotice3. Back-patch to v14 where ffa2e4670 came in. In principle this could go back further; but in view of the lack of field reports, the hazard seems negligible in older branches. Discussion: https://postgr.es/m/530153.1627425648@sss.pgh.pa.us
2021-07-29 19:33:31 +02:00
/*
* The errorMessage buffer might be marked "broken" due to having
* previously failed to allocate enough memory for the message. In that
* case, tell the application we ran out of memory.
*/
if (PQExpBufferBroken(&conn->errorMessage))
return libpq_gettext("out of memory\n");
Update frontend libpq to remove limits on query lengths, error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
1999-08-31 03:37:37 +02:00
return conn->errorMessage.data;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
check socket creation errors against PGINVALID_SOCKET Previously, in some places, socket creation errors were checked for negative values, which is not true for Windows because sockets are unsigned. This masked socket creation errors on Windows. Backpatch through 9.0. 8.4 doesn't have the infrastructure to fix this.
2014-04-16 16:45:48 +02:00
/*
* In Windows, socket values are unsigned, and an invalid socket value
* (INVALID_SOCKET) is ~0, which equals -1 in comparisons (with no compiler
* warning). Ideally we would return an unsigned value for PQsocket() on
* Windows, but that would cause the function's return value to differ from
* Unix, so we just return -1 for invalid sockets.
* http://msdn.microsoft.com/en-us/library/windows/desktop/cc507522%28v=vs.85%29.aspx
* http://stackoverflow.com/questions/10817252/why-is-invalid-socket-defined-as-0-in-winsock2-h-c
*/
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
int
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
PQsocket(const PGconn *conn)
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
{
if (!conn)
return -1;
libpq: use pgsocket for socket values, for portability Previously, 'int' was used for socket values in libpq, but socket values are unsigned on Windows. This is a style correction. Initial patch and previous PGINVALID_SOCKET initial patch by Joel Jacobson, modified by me Report from PVS-Studio
2014-04-17 01:46:51 +02:00
return (conn->sock != PGINVALID_SOCKET) ? conn->sock : -1;
What I've done: 1. Rewritten libpq to allow asynchronous clients. 2. Implemented client side of cancel protocol in library, and patched psql.c to send a cancel request upon SIGINT. The backend doesn't notice it yet :-( 3. Implemented 'Z' protocol message addition and renaming of copy in/out start messages. These are implemented conditionally, ie, the client protocol version is checked; so the code should still work with 1.0 clients. 4. Revised protocol and libpq sgml documents (don't have an SGML compiler, though, so there may be some markup glitches here). What remains to be done: 1. Implement addition of atttypmod field to RowDescriptor messages. The client-side code is there but ifdef'd out. I have no idea what to change on the backend side. The field should be sent only if protocol >= 2.0, of course. 2. Implement backend response to cancel requests received as OOB messages. (This prolly need not be conditional on protocol version; just do it if you get SIGURG.) 3. Update libpq.3. (I'm hoping this can be generated mechanically from libpq.sgml... if not, will do it by hand.) Is there any other doco to fix? 4. Update non-libpq interfaces as necessary. I patched libpgtcl so that it would compile, but haven't tested it. Dunno what needs to be done with the other interfaces. Have at it! Tom Lane
1998-05-07 01:51:16 +02:00
}
Attached is a patch to remove the definitions of libpq's internal structs from libpq-fe.h, as we previously discussed. There turned out to be sloppy coding practices in more places than I had realized :-(, but all in all I think it was a well-worth-while exercise. I ended up adding several routines to libpq's API in order to respond to application requirements that were exposed by this work. I owe the docs crew updates for libpq.sgml to describe these changes. I'm way too tired to work on the docs tonight, however. This is the last major change I intend to submit for 6.4. I do want to see if I can make libpgtcl work with Tcl 8.0 before we go final, but hopefully that will be a minor bug fix.
1998-09-03 04:10:56 +02:00
int
In the spirit of TODO item * Add use of 'const' for varibles in source tree (which is misspelled, btw.) I went through the front-end libpq code and did so. This affects in particular the various accessor functions (such as PQdb() and PQgetvalue()) as well as, by necessity, the internal helpers they use. I have been really thorough in that regard, perhaps some people will find it annoying that things like char * foo = PQgetvalue(res, 0, 0) will generate a warning. On the other hand it _should_ generate one. This is no real compatibility break, although a few clients will have to be fixed to suppress warnings. (Which again would be in the spirit of the above TODO.) In addition I replaced some int's by size_t's and removed some warnings (and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it actually honors the const!) and supplied a new function PQoidValue that returns a proper Oid type. This is only front-end stuff, none of the communicaton stuff was touched. The psql patch also adds some new consts to honor the new libpq situation, as well as fixes a fatal condition that resulted when using the -V (--version) option and there is no database listening. So, to summarize, the psql you should definitely put in (with or without the libpq). If you think I went too far with the const-mania in libpq, let me know and I'll make adjustments. If you approve it, I will also update the docs. -Peter -- Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
PQbackendPID(const PGconn *conn)
Attached is a patch to remove the definitions of libpq's internal structs from libpq-fe.h, as we previously discussed. There turned out to be sloppy coding practices in more places than I had realized :-(, but all in all I think it was a well-worth-while exercise. I ended up adding several routines to libpq's API in order to respond to application requirements that were exposed by this work. I owe the docs crew updates for libpq.sgml to describe these changes. I'm way too tired to work on the docs tonight, however. This is the last major change I intend to submit for 6.4. I do want to see if I can make libpgtcl work with Tcl 8.0 before we go final, but hopefully that will be a minor bug fix.
1998-09-03 04:10:56 +02:00
{
if (!conn || conn->status != CONNECTION_OK)
return 0;
return conn->be_pid;
}
Implement pipeline mode in libpq Pipeline mode in libpq lets an application avoid the Sync messages in the FE/BE protocol that are implicit in the old libpq API after each query. The application can then insert Sync at its leisure with a new libpq function PQpipelineSync. This can lead to substantial reductions in query latency. Co-authored-by: Craig Ringer <craig.ringer@enterprisedb.com> Co-authored-by: Matthieu Garrigues <matthieu.garrigues@gmail.com> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Aya Iwata <iwata.aya@jp.fujitsu.com> Reviewed-by: Daniel Vérité <daniel@manitou-mail.org> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Kirk Jamison <k.jamison@fujitsu.com> Reviewed-by: Michael Paquier <michael.paquier@gmail.com> Reviewed-by: Nikhil Sontakke <nikhils@2ndquadrant.com> Reviewed-by: Vaishnavi Prabakaran <VaishnaviP@fast.au.fujitsu.com> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Discussion: https://postgr.es/m/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com Discussion: https://postgr.es/m/CAJkzx4T5E-2cQe3dtv2R78dYFvz+in8PY7A8MArvLhs_pg75gg@mail.gmail.com
2021-03-15 22:13:42 +01:00
PGpipelineStatus
PQpipelineStatus(const PGconn *conn)
{
if (!conn)
return PQ_PIPELINE_OFF;
return conn->pipelineStatus;
}
Fix up the PQconnectionUsedPassword mess: create a separate PQconnectionNeedsPassword function that tells the right thing for whether to prompt for a password, and improve PQconnectionUsedPassword so that it checks whether the password used by the connection was actually supplied as a connection argument, instead of coming from environment or a password file. Per bug report from Mark Cave-Ayland and subsequent discussion.
2007-12-09 20:01:40 +01:00
int
PQconnectionNeedsPassword(const PGconn *conn)
{
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
char *password;
Fix up the PQconnectionUsedPassword mess: create a separate PQconnectionNeedsPassword function that tells the right thing for whether to prompt for a password, and improve PQconnectionUsedPassword so that it checks whether the password used by the connection was actually supplied as a connection argument, instead of coming from environment or a password file. Per bug report from Mark Cave-Ayland and subsequent discussion.
2007-12-09 20:01:40 +01:00
if (!conn)
return false;
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
password = PQpass(conn);
Fix up the PQconnectionUsedPassword mess: create a separate PQconnectionNeedsPassword function that tells the right thing for whether to prompt for a password, and improve PQconnectionUsedPassword so that it checks whether the password used by the connection was actually supplied as a connection argument, instead of coming from environment or a password file. Per bug report from Mark Cave-Ayland and subsequent discussion.
2007-12-09 20:01:40 +01:00
if (conn->password_needed &&
libpq: Allow connection strings and URIs to specify multiple hosts. It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
2016-11-03 14:25:20 +01:00
(password == NULL || password[0] == '\0'))
Fix up the PQconnectionUsedPassword mess: create a separate PQconnectionNeedsPassword function that tells the right thing for whether to prompt for a password, and improve PQconnectionUsedPassword so that it checks whether the password used by the connection was actually supplied as a connection argument, instead of coming from environment or a password file. Per bug report from Mark Cave-Ayland and subsequent discussion.
2007-12-09 20:01:40 +01:00
return true;
else
return false;
}
Closer code review for PQconnectionUsedPassword() patch: in particular, not OK to include postgres_fe.h into libpq-fe.h, hence declare it as returning int not bool.
2007-07-08 20:28:56 +02:00
int
PQconnectionUsedPassword(const PGconn *conn)
{
if (!conn)
return false;
Get rid of pgpass_from_client tracking inside libpq --- given the conclusion that presence of the password in the conninfo string must be checked *before* risking a connection attempt, there is no point in checking it afterwards. This makes the specification of PQconnectionUsedPassword() a bit simpler and perhaps more generally useful, too.
2008-09-22 16:21:44 +02:00
if (conn->password_needed)
Closer code review for PQconnectionUsedPassword() patch: in particular, not OK to include postgres_fe.h into libpq-fe.h, hence declare it as returning int not bool.
2007-07-08 20:28:56 +02:00
return true;
else
return false;
}
Eliminate using putenv().
2000-01-15 06:37:21 +01:00
int
Change function name PQclientencoding to PQclientEncoding since it seems more suitable for the naming convention in libpq. New function PQsetClientEncoding added. It makes possible to change the client encoding on the fly without setting PGCLIENTENCODING.
2000-02-05 13:33:22 +01:00
PQclientEncoding(const PGconn *conn)
Eliminate using putenv().
2000-01-15 06:37:21 +01:00
{
if (!conn || conn->status != CONNECTION_OK)
return -1;
return conn->client_encoding;
}
Change function name PQclientencoding to PQclientEncoding since it seems more suitable for the naming convention in libpq. New function PQsetClientEncoding added. It makes possible to change the client encoding on the fly without setting PGCLIENTENCODING.
2000-02-05 13:33:22 +01:00
int
PQsetClientEncoding(PGconn *conn, const char *encoding)
{
char qbuf[128];
Add thread locking to SSL and Kerberos connections. I have removed the docs mentioning that SSL and Kerberos are not thread-safe. Manfred Spraul
2004-03-24 04:45:00 +01:00
static const char query[] = "set client_encoding to '%s'";
Change function name PQclientencoding to PQclientEncoding since it seems more suitable for the naming convention in libpq. New function PQsetClientEncoding added. It makes possible to change the client encoding on the fly without setting PGCLIENTENCODING.
2000-02-05 13:33:22 +01:00
PGresult *res;
int status;
if (!conn || conn->status != CONNECTION_OK)
return -1;
Fix nasty bug in setting client_encoding
2000-02-19 06:04:54 +01:00
if (!encoding)
return -1;
Set psql client encoding from locale by default Add a new libpq connection option client_encoding (which includes the existing PGCLIENTENCODING environment variable), which besides an encoding name accepts a special value "auto" that tries to determine the encoding from the locale in the client's environment, using the mechanisms that have been in use in initdb. psql sets this new connection option to "auto" when running from a terminal and not overridden by setting PGCLIENTENCODING. original code by Heikki Linnakangas, with subsequent contributions by Jaime Casanova, Peter Eisentraut, Stephen Frost, Ibrar Ahmed
2011-02-19 07:54:58 +01:00
/* Resolve special "auto" value from the locale */
if (strcmp(encoding, "auto") == 0)
encoding = pg_encoding_to_char(pg_get_encoding_from_locale(NULL, true));
Change function name PQclientencoding to PQclientEncoding since it seems more suitable for the naming convention in libpq. New function PQsetClientEncoding added. It makes possible to change the client encoding on the fly without setting PGCLIENTENCODING.
2000-02-05 13:33:22 +01:00
/* check query buffer overflow */
if (sizeof(qbuf) < (sizeof(query) + strlen(encoding)))
return -1;
/* ok, now send a query */
sprintf(qbuf, query, encoding);
res = PQexec(conn, qbuf);
More janitorial work: remove the explicit casting of NULL literals to a pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
2004-01-07 19:56:30 +01:00
if (res == NULL)
Change function name PQclientencoding to PQclientEncoding since it seems more suitable for the naming convention in libpq. New function PQsetClientEncoding added. It makes possible to change the client encoding on the fly without setting PGCLIENTENCODING.
2000-02-05 13:33:22 +01:00
return -1;
if (res->resultStatus != PGRES_COMMAND_OK)
status = -1;
else
{
Modify libpq's string-escaping routines to be aware of encoding considerations and standard_conforming_strings. The encoding changes are needed for proper escaping in multibyte encodings, as per the SQL-injection vulnerabilities noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied to the server to ensure that it rejects queries that may have been corrupted by attempted SQL injection, but this merely guarantees that unpatched clients will fail rather than allow injection. An actual fix requires changing the client-side code. While at it we have also fixed these routines to understand about standard_conforming_strings, so that the upcoming changeover to SQL-spec string syntax can be somewhat transparent to client code. Since the existing API of PQescapeString and PQescapeBytea provides no way to inform them which settings are in use, these functions are now deprecated in favor of new functions PQescapeStringConn and PQescapeByteaConn. The new functions take the PGconn to which the string will be sent as an additional parameter, and look inside the connection structure to determine what to do. So as to provide some functionality for clients using the old functions, libpq stores the latest encoding and standard_conforming_strings values received from the backend in static variables, and the old functions consult these variables. This will work reliably in clients using only one Postgres connection at a time, or even multiple connections if they all use the same encoding and string syntax settings; which should cover many practical scenarios. Clients that use homebrew escaping methods, such as PHP's addslashes() function or even hardwired regexp substitution, will require extra effort to fix :-(. It is strongly recommended that such code be replaced by use of PQescapeStringConn/PQescapeByteaConn if at all feasible.
2006-05-21 22:19:23 +02:00
/*
Remove server and libpq support for old FE/BE protocol version 2. Protocol version 3 was introduced in PostgreSQL 7.4. There shouldn't be many clients or servers left out there without version 3 support. But as a courtesy, I kept just enough of the old protocol support that we can still send the "unsupported protocol version" error in v2 format, so that old clients can display the message properly. Likewise, libpq still understands v2 ErrorResponse messages when establishing a connection. The impetus to do this now is that I'm working on a patch to COPY FROM, to always prefetch some data. We cannot do that safely with the old protocol, because it requires parsing the input one byte at a time to detect the end-of-copy marker. Reviewed-by: Tom Lane, Alvaro Herrera, John Naylor Discussion: https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cca3b%40iki.fi
2021-03-04 09:45:55 +01:00
* We rely on the backend to report the parameter value, and we'll
* change state at that time.
Modify libpq's string-escaping routines to be aware of encoding considerations and standard_conforming_strings. The encoding changes are needed for proper escaping in multibyte encodings, as per the SQL-injection vulnerabilities noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied to the server to ensure that it rejects queries that may have been corrupted by attempted SQL injection, but this merely guarantees that unpatched clients will fail rather than allow injection. An actual fix requires changing the client-side code. While at it we have also fixed these routines to understand about standard_conforming_strings, so that the upcoming changeover to SQL-spec string syntax can be somewhat transparent to client code. Since the existing API of PQescapeString and PQescapeBytea provides no way to inform them which settings are in use, these functions are now deprecated in favor of new functions PQescapeStringConn and PQescapeByteaConn. The new functions take the PGconn to which the string will be sent as an additional parameter, and look inside the connection structure to determine what to do. So as to provide some functionality for clients using the old functions, libpq stores the latest encoding and standard_conforming_strings values received from the backend in static variables, and the old functions consult these variables. This will work reliably in clients using only one Postgres connection at a time, or even multiple connections if they all use the same encoding and string syntax settings; which should cover many practical scenarios. Clients that use homebrew escaping methods, such as PHP's addslashes() function or even hardwired regexp substitution, will require extra effort to fix :-(. It is strongly recommended that such code be replaced by use of PQescapeStringConn/PQescapeByteaConn if at all feasible.
2006-05-21 22:19:23 +02:00
*/
Change function name PQclientencoding to PQclientEncoding since it seems more suitable for the naming convention in libpq. New function PQsetClientEncoding added. It makes possible to change the client encoding on the fly without setting PGCLIENTENCODING.
2000-02-05 13:33:22 +01:00
status = 0; /* everything is ok */
}
PQclear(res);
Cosmetic code cleanup: fix a bunch of places that used "return (expr);" rather than "return expr;" -- the latter style is used in most of the tree. I kept the parentheses when they were necessary or useful because the return expression was complex.
2006-01-11 09:43:13 +01:00
return status;
Change function name PQclientencoding to PQclientEncoding since it seems more suitable for the naming convention in libpq. New function PQsetClientEncoding added. It makes possible to change the client encoding on the fly without setting PGCLIENTENCODING.
2000-02-05 13:33:22 +01:00
}
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
PGVerbosity
PQsetErrorVerbosity(PGconn *conn, PGVerbosity verbosity)
{
PGVerbosity old;
if (!conn)
return PQERRORS_DEFAULT;
old = conn->verbosity;
conn->verbosity = verbosity;
return old;
}
Rearrange the handling of error context reports. Remove the code in plpgsql that suppressed the innermost line of CONTEXT for messages emitted by RAISE commands. That was never more than a quick backwards-compatibility hack, and it's pretty silly in cases where the RAISE is nested in several levels of function. What's more, it violated our design theory that verbosity of error reports should be controlled on the client side not the server side. To alleviate the resulting noise increase, introduce a feature in libpq and psql whereby the CONTEXT field of messages can be suppressed, either always or only for non-error messages. Printing CONTEXT for errors only is now their default behavior. The actual code changes here are pretty small, but the effects on the regression test outputs are widespread. I had to edit some of the alternative expected outputs by hand; hopefully the buildfarm will soon find anything I fat-fingered. In passing, fix up (again) the output line counts in psql's various help displays. Add some commentary about how to verify them. Pavel Stehule, reviewed by Petr Jelínek, Jeevan Chalke, and others
2015-09-05 17:58:20 +02:00
PGContextVisibility
PQsetErrorContextVisibility(PGconn *conn, PGContextVisibility show_context)
{
PGContextVisibility old;
if (!conn)
return PQSHOW_CONTEXT_ERRORS;
old = conn->show_context;
conn->show_context = show_context;
return old;
}
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
PQnoticeReceiver
PQsetNoticeReceiver(PGconn *conn, PQnoticeReceiver proc, void *arg)
{
PQnoticeReceiver old;
if (conn == NULL)
return NULL;
old = conn->noticeHooks.noticeRec;
if (proc)
{
conn->noticeHooks.noticeRec = proc;
conn->noticeHooks.noticeRecArg = arg;
}
return old;
}
These are two minor corrections to libpq's PQsetNoticeProcessor function. One, it now returns the previous hook. That way people don't have to dig around in libpq-int.h for that information anymore. It previously returned void, so there should be no incompatibilities. Second, you cannot set the callback to NULL anymore. (Of course you can still call it with NULL just to get the current hook.) The way libpq uses the callback pointer, having a NULL there wasn't very healthy. Peter Eisentraut
1999-10-26 06:49:00 +02:00
PQnoticeProcessor
The attached patch implements some changes that were discussed a couple weeks ago on the hackers and interfaces lists: 1. When the backend sends a NOTICE message and closes the connection (typically, because it was told to by the postmaster after another backend coredumped), libpq will now print the notice and close the connection cleanly. Formerly, the frontend app would usually terminate ungracefully due to a SIGPIPE. (I am not sure if 6.3.2 behaved that way, but the current cvs sources do...) 2. libpq's various printouts to stderr are now fed through a single "notice processor" routine, which can be overridden by the application to direct notices someplace else. This should ease porting libpq to Windows. I also noticed and fixed a problem in PQprint: when sending output to a pager subprocess, it would disable SIGPIPE in case the pager terminates early (this is good) --- but afterwards it reset SIGPIPE to SIG_DFL, rather than restoring the application's prior setting (bad). regards, tom lane
1998-08-09 04:59:33 +02:00
PQsetNoticeProcessor(PGconn *conn, PQnoticeProcessor proc, void *arg)
{
These are two minor corrections to libpq's PQsetNoticeProcessor function. One, it now returns the previous hook. That way people don't have to dig around in libpq-int.h for that information anymore. It previously returned void, so there should be no incompatibilities. Second, you cannot set the callback to NULL anymore. (Of course you can still call it with NULL just to get the current hook.) The way libpq uses the callback pointer, having a NULL there wasn't very healthy. Peter Eisentraut
1999-10-26 06:49:00 +02:00
PQnoticeProcessor old;
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
The attached patch implements some changes that were discussed a couple weeks ago on the hackers and interfaces lists: 1. When the backend sends a NOTICE message and closes the connection (typically, because it was told to by the postmaster after another backend coredumped), libpq will now print the notice and close the connection cleanly. Formerly, the frontend app would usually terminate ungracefully due to a SIGPIPE. (I am not sure if 6.3.2 behaved that way, but the current cvs sources do...) 2. libpq's various printouts to stderr are now fed through a single "notice processor" routine, which can be overridden by the application to direct notices someplace else. This should ease porting libpq to Windows. I also noticed and fixed a problem in PQprint: when sending output to a pager subprocess, it would disable SIGPIPE in case the pager terminates early (this is good) --- but afterwards it reset SIGPIPE to SIG_DFL, rather than restoring the application's prior setting (bad). regards, tom lane
1998-08-09 04:59:33 +02:00
if (conn == NULL)
These are two minor corrections to libpq's PQsetNoticeProcessor function. One, it now returns the previous hook. That way people don't have to dig around in libpq-int.h for that information anymore. It previously returned void, so there should be no incompatibilities. Second, you cannot set the callback to NULL anymore. (Of course you can still call it with NULL just to get the current hook.) The way libpq uses the callback pointer, having a NULL there wasn't very healthy. Peter Eisentraut
1999-10-26 06:49:00 +02:00
return NULL;
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
old = conn->noticeHooks.noticeProc;
Change PQconndefaults() to return a malloc'd array, instead of a static array. This allows processing of conninfo strings to be made thread-safe, at the cost of a small memory leak in applications that use PQconndefaults() and are not updated to free the returned array via the new PQconninfoFree() function. But PQconndefaults() is probably not used very much, so this seems like a good compromise.
2000-03-11 04:08:37 +01:00
if (proc)
{
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
conn->noticeHooks.noticeProc = proc;
conn->noticeHooks.noticeProcArg = arg;
These are two minor corrections to libpq's PQsetNoticeProcessor function. One, it now returns the previous hook. That way people don't have to dig around in libpq-int.h for that information anymore. It previously returned void, so there should be no incompatibilities. Second, you cannot set the callback to NULL anymore. (Of course you can still call it with NULL just to get the current hook.) The way libpq uses the callback pointer, having a NULL there wasn't very healthy. Peter Eisentraut
1999-10-26 06:49:00 +02:00
}
return old;
The attached patch implements some changes that were discussed a couple weeks ago on the hackers and interfaces lists: 1. When the backend sends a NOTICE message and closes the connection (typically, because it was told to by the postmaster after another backend coredumped), libpq will now print the notice and close the connection cleanly. Formerly, the frontend app would usually terminate ungracefully due to a SIGPIPE. (I am not sure if 6.3.2 behaved that way, but the current cvs sources do...) 2. libpq's various printouts to stderr are now fed through a single "notice processor" routine, which can be overridden by the application to direct notices someplace else. This should ease porting libpq to Windows. I also noticed and fixed a problem in PQprint: when sending output to a pager subprocess, it would disable SIGPIPE in case the pager terminates early (this is good) --- but afterwards it reset SIGPIPE to SIG_DFL, rather than restoring the application's prior setting (bad). regards, tom lane
1998-08-09 04:59:33 +02:00
}
/*
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
* The default notice message receiver just gets the standard notice text
* and sends it to the notice processor. This two-level setup exists
* mostly for backwards compatibility; perhaps we should deprecate use of
* PQsetNoticeProcessor?
*/
static void
defaultNoticeReceiver(void *arg, const PGresult *res)
{
(void) arg; /* not used */
Change pqInternalNotice to accept a format string and args instead of just a preformatted message; per suggestion by Sean Chittenden.
2003-06-23 21:20:25 +02:00
if (res->noticeHooks.noticeProc != NULL)
Reduce excessive dereferencing of function pointers It is equivalent in ANSI C to write (*funcptr) () and funcptr(). These two styles have been applied inconsistently. After discussion, we'll use the more verbose style for plain function pointer variables, to make it clear that it's a variable, and the shorter style when the function pointer is in a struct (s.func() or s->func()), because then it's clear that it's not a plain function name, and otherwise the excessive punctuation makes some of those invocations hard to read. Discussion: https://www.postgresql.org/message-id/f52c16db-14ed-757d-4b48-7ef360b1631d@2ndquadrant.com
2017-09-07 18:06:23 +02:00
res->noticeHooks.noticeProc(res->noticeHooks.noticeProcArg,
PQresultErrorMessage(res));
Update libpq to make new features of FE/BE protocol available to client applications. Some editorial work on libpq.sgml, too.
2003-06-21 23:51:35 +02:00
}
/*
* The default notice message processor just prints the
The attached patch implements some changes that were discussed a couple weeks ago on the hackers and interfaces lists: 1. When the backend sends a NOTICE message and closes the connection (typically, because it was told to by the postmaster after another backend coredumped), libpq will now print the notice and close the connection cleanly. Formerly, the frontend app would usually terminate ungracefully due to a SIGPIPE. (I am not sure if 6.3.2 behaved that way, but the current cvs sources do...) 2. libpq's various printouts to stderr are now fed through a single "notice processor" routine, which can be overridden by the application to direct notices someplace else. This should ease porting libpq to Windows. I also noticed and fixed a problem in PQprint: when sending output to a pager subprocess, it would disable SIGPIPE in case the pager terminates early (this is good) --- but afterwards it reset SIGPIPE to SIG_DFL, rather than restoring the application's prior setting (bad). regards, tom lane
1998-08-09 04:59:33 +02:00
* message on stderr. Applications can override this if they
* want the messages to go elsewhere (a window, for example).
* Note that simply discarding notices is probably a bad idea.
*/
static void
defaultNoticeProcessor(void *arg, const char *message)
{
Fixed psql double quoting of SQL ids Fixed libpq printing functions
2000-02-08 00:10:11 +01:00
(void) arg; /* not used */
The attached patch implements some changes that were discussed a couple weeks ago on the hackers and interfaces lists: 1. When the backend sends a NOTICE message and closes the connection (typically, because it was told to by the postmaster after another backend coredumped), libpq will now print the notice and close the connection cleanly. Formerly, the frontend app would usually terminate ungracefully due to a SIGPIPE. (I am not sure if 6.3.2 behaved that way, but the current cvs sources do...) 2. libpq's various printouts to stderr are now fed through a single "notice processor" routine, which can be overridden by the application to direct notices someplace else. This should ease porting libpq to Windows. I also noticed and fixed a problem in PQprint: when sending output to a pager subprocess, it would disable SIGPIPE in case the pager terminates early (this is good) --- but afterwards it reset SIGPIPE to SIG_DFL, rather than restoring the application's prior setting (bad). regards, tom lane
1998-08-09 04:59:33 +02:00
/* Note: we expect the supplied string to end with a newline already. */
fprintf(stderr, "%s", message);
}
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
/*
* returns a pointer to the next token or NULL if the current
* token doesn't match
*/
static char *
Add some const decorations to prototypes Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
2017-10-31 15:34:31 +01:00
pwdfMatchesString(char *buf, const char *token)
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
{
Add some const decorations to prototypes Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
2017-10-31 15:34:31 +01:00
char *tbuf;
const char *ttok;
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
bool bslash = false;
pgindent run.
2002-09-04 22:31:48 +02:00
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
if (buf == NULL || token == NULL)
return NULL;
tbuf = buf;
ttok = token;
Make pwdfMatchesString() a little more careful about matching * fields.
2009-05-18 18:15:22 +02:00
if (tbuf[0] == '*' && tbuf[1] == ':')
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
return tbuf + 2;
while (*tbuf != 0)
{
if (*tbuf == '\\' && !bslash)
{
tbuf++;
bslash = true;
}
if (*tbuf == ':' && *ttok == 0 && !bslash)
return tbuf + 1;
bslash = false;
if (*ttok == 0)
return NULL;
if (*tbuf == *ttok)
{
tbuf++;
ttok++;
}
else
return NULL;
}
return NULL;
}
Fix regression in .pgpass support. From Neil Conway.
2003-01-30 20:49:54 +01:00
/* Get a password from the password file. Return value is malloc'd. */
First phase of FE/BE protocol modifications: new StartupPacket layout with variable-width fields. No more truncation of long user names. Also, libpq can now send its environment-variable-driven SET commands as part of the startup packet, saving round trips to server.
2003-04-18 00:26:02 +02:00
static char *
Add some const decorations to prototypes Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
2017-10-31 15:34:31 +01:00
passwordFromFile(const char *hostname, const char *port, const char *dbname,
const char *username, const char *pgpassfile)
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
{
FILE *fp;
Remove PGPASSWORDFILE and default to always trying $HOME/.pgpass. Cleanup up memory allocation for $HOME in related psql places. Update mention of $HOME/.pgpass in the docs; add mention in pg_dumpall.
2002-09-06 00:05:50 +02:00
struct stat stat_buf;
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
PQExpBufferData buf;
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
if (dbname == NULL || dbname[0] == '\0')
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
return NULL;
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
if (username == NULL || username[0] == '\0')
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
return NULL;
Allow the .pgpass hostname to match the default socket directory, as well as a blank pghost.
2006-05-17 23:50:54 +02:00
/* 'localhost' matches pghost of '' or the default socket directory */
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
if (hostname == NULL || hostname[0] == '\0')
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
hostname = DefaultHost;
Add support for abstract Unix-domain sockets This is a variant of the normal Unix-domain sockets that don't use the file system but a separate "abstract" namespace. At the user interface, such sockets are represented by names starting with "@". Supported on Linux and Windows right now. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/6dee8574-b0ad-fc49-9c8c-2edc796f0033@2ndquadrant.com
2020-11-25 08:14:23 +01:00
else if (is_unixsock_path(hostname))
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Remove canonicalize_path() call for .pgpass socket directory comparison; not worth adding path.c to libpq.
2006-05-18 18:26:44 +02:00
/*
* We should probably use canonicalize_path(), but then we have to
* bring path.c into libpq, and it doesn't seem worth it.
*/
if (strcmp(hostname, DEFAULT_PGSOCKET_DIR) == 0)
Allow the .pgpass hostname to match the default socket directory, as well as a blank pghost.
2006-05-17 23:50:54 +02:00
hostname = DefaultHost;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Fix libpq's code for searching .pgpass; rationalize empty-list-item cases. Before v10, we always searched ~/.pgpass using the host parameter, and nothing else, to match to the "hostname" field of ~/.pgpass. (However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by "localhost".) In v10, this got broken by commit 274bb2b38, repaired by commit bdac9836d, and broken again by commit 7b02ba62e; in the code actually shipped, we'd search with hostaddr if both that and host were specified --- though oddly, *not* if only hostaddr were specified. Since this is directly contrary to the documentation, and not backwards-compatible, it's clearly a bug. However, the change wasn't totally without justification, even though it wasn't done quite right, because the pre-v10 behavior has arguably been buggy since we added hostaddr. If hostaddr is specified and host isn't, the pre-v10 code will search ~/.pgpass for "localhost", and ship that password off to a server that most likely isn't local at all. That's unhelpful at best, and could be a security breach at worst. Therefore, rather than just revert to that old behavior, let's define the behavior as "search with host if provided, else with hostaddr if provided, else search for localhost". (As before, a host name matching DEFAULT_PGSOCKET_DIR is replaced by localhost.) This matches the behavior of the actual connection code, so that we don't pick up an inappropriate password; and it allows useful searches to happen when only hostaddr is given. While we're messing around here, ensure that empty elements within a host or hostaddr list select the same behavior as a totally-empty field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b" if DEFAULT_PGSOCKET_DIR is /tmp. Things worked that way in some cases already, but not consistently so, which contributed to the confusion about what key ~/.pgpass would get searched with. Update documentation accordingly, and also clarify some nearby text. Back-patch to v10 where the host/hostaddr list functionality was introduced. Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us
2018-08-01 18:30:36 +02:00
if (port == NULL || port[0] == '\0')
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
port = DEF_PGPORT_STR;
> > > > If you want to put in security restrictions that are actually useful, > > > > where is the code to verify that PGPASSWORDFILE points at a > > > > non-world-readable file? That needs to be there now, not later, or > > > > we'll have people moaning about backward compatibility when we finally > > > > do plug that hole. Alvaro Herrera
2002-08-30 01:06:32 +02:00
/* If password file cannot be opened, ignore it. */
Use error message wordings for permissions checks on .pgpass and SSL private key files that are similar to the one for the postmaster's data directory permissions check. (I chose to standardize on that one since it's the most heavily used and presumably best-wordsmithed by now.) Also eliminate explicit tests on file ownership in these places, since the ensuing read attempt must fail anyway if it's wrong, and there seems no value in issuing the same error message for distinct problems. (But I left in the explicit ownership test in postmaster.c, since it had its own error message anyway.) Also be more specific in the documentation's descriptions of these checks. Per a gripe from Kevin Hunter.
2008-03-31 04:43:14 +02:00
if (stat(pgpassfile, &stat_buf) != 0)
> > > > If you want to put in security restrictions that are actually useful, > > > > where is the code to verify that PGPASSWORDFILE points at a > > > > non-world-readable file? That needs to be there now, not later, or > > > > we'll have people moaning about backward compatibility when we finally > > > > do plug that hole. Alvaro Herrera
2002-08-30 01:06:32 +02:00
return NULL;
Cleanup for Win32 compile. Andreas Pflug
2005-06-19 15:10:56 +02:00
#ifndef WIN32
Add the "PGPASSFILE" environment variable to specify to the password file. Andrew Dunstan
2005-06-10 05:02:30 +02:00
if (!S_ISREG(stat_buf.st_mode))
{
fprintf(stderr,
Don't need gettext calls around debug messages.
2005-09-26 19:49:09 +02:00
libpq_gettext("WARNING: password file \"%s\" is not a plain file\n"),
Add the "PGPASSFILE" environment variable to specify to the password file. Andrew Dunstan
2005-06-10 05:02:30 +02:00
pgpassfile);
return NULL;
}
> > > > If you want to put in security restrictions that are actually useful, > > > > where is the code to verify that PGPASSWORDFILE points at a > > > > non-world-readable file? That needs to be there now, not later, or > > > > we'll have people moaning about backward compatibility when we finally > > > > do plug that hole. Alvaro Herrera
2002-08-30 01:06:32 +02:00
/* If password file is insecure, alert the user and ignore it. */
if (stat_buf.st_mode & (S_IRWXG | S_IRWXO))
{
fprintf(stderr,
Use error message wordings for permissions checks on .pgpass and SSL private key files that are similar to the one for the postmaster's data directory permissions check. (I chose to standardize on that one since it's the most heavily used and presumably best-wordsmithed by now.) Also eliminate explicit tests on file ownership in these places, since the ensuing read attempt must fail anyway if it's wrong, and there seems no value in issuing the same error message for distinct problems. (But I left in the explicit ownership test in postmaster.c, since it had its own error message anyway.) Also be more specific in the documentation's descriptions of these checks. Per a gripe from Kevin Hunter.
2008-03-31 04:43:14 +02:00
libpq_gettext("WARNING: password file \"%s\" has group or world access; permissions should be u=rw (0600) or less\n"),
Remove PGPASSWORDFILE and default to always trying $HOME/.pgpass. Cleanup up memory allocation for $HOME in related psql places. Update mention of $HOME/.pgpass in the docs; add mention in pg_dumpall.
2002-09-06 00:05:50 +02:00
pgpassfile);
> > > > If you want to put in security restrictions that are actually useful, > > > > where is the code to verify that PGPASSWORDFILE points at a > > > > non-world-readable file? That needs to be there now, not later, or > > > > we'll have people moaning about backward compatibility when we finally > > > > do plug that hole. Alvaro Herrera
2002-08-30 01:06:32 +02:00
return NULL;
}
Add comment that on Win32, we don't need to check the .pgpass file permission, per Magnus.
2007-02-20 16:20:51 +01:00
#else
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Add comment that on Win32, we don't need to check the .pgpass file permission, per Magnus.
2007-02-20 16:20:51 +01:00
/*
* On Win32, the directory is protected, so we don't have to check the
* file.
*/
The attached patch fixes a number of issues related to compiling the client utilities (libpq.dll and psql.exe) for win32 (missing defines, adjustments to includes, pedantic casting, non-existent functions) per: http://developer.postgresql.org/docs/postgres/install-win32.html. It compiles cleanly under Windows 2000 using Visual Studio .net. Also compiles clean and passes all regression tests (regular and contrib) under Linux. In addition to a review by the usual suspects, it would be very desirable for someone well versed in the peculiarities of win32 to take a look. Joe Conway
2002-10-03 19:09:42 +02:00
#endif
> > > > If you want to put in security restrictions that are actually useful, > > > > where is the code to verify that PGPASSWORDFILE points at a > > > > non-world-readable file? That needs to be there now, not later, or > > > > we'll have people moaning about backward compatibility when we finally > > > > do plug that hole. Alvaro Herrera
2002-08-30 01:06:32 +02:00
Remove PGPASSWORDFILE and default to always trying $HOME/.pgpass. Cleanup up memory allocation for $HOME in related psql places. Update mention of $HOME/.pgpass in the docs; add mention in pg_dumpall.
2002-09-06 00:05:50 +02:00
fp = fopen(pgpassfile, "r");
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
if (fp == NULL)
return NULL;
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
/* Use an expansible buffer to accommodate any reasonable line length */
initPQExpBuffer(&buf);
Fix a couple of places that would loop forever if attempts to read a stdio file set ferror() but never set feof(). This is known to be the case for recent glibc when trying to read a directory as a file, and might be true for other platforms/cases too. Per report from Ed L. (There is more that we ought to do about his report, but this is one easily identifiable issue.)
2010-03-03 21:31:09 +01:00
while (!feof(fp) && !ferror(fp))
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
{
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
/* Make sure there's a reasonable amount of room in the buffer */
if (!enlargePQExpBuffer(&buf, 128))
break;
pgindent run.
2002-09-04 22:31:48 +02:00
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
/* Read some data, appending it to what we already have */
if (fgets(buf.data + buf.len, buf.maxlen - buf.len, fp) == NULL)
Fix a couple of places where the result of fgets() wasn't checked. This is mostly to suppress compiler warnings, although in principle the cases could result in undesirable behavior. Martin Pitt
2010-04-30 19:09:13 +02:00
break;
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
buf.len += strlen(buf.data + buf.len);
Fix regression in .pgpass support. From Neil Conway.
2003-01-30 20:49:54 +01:00
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
/* If we don't yet have a whole line, loop around to read more */
if (!(buf.len > 0 && buf.data[buf.len - 1] == '\n') && !feof(fp))
continue;
/* ignore comments */
if (buf.data[0] != '#')
Fix issues around .pgpass file. This commit fixes the following two issues around .pgpass file. (1) If the length of a line in .pgpass file was larger than 319B, libpq silently treated each 319B in the line as a separate setting line. (2) The document explains that a line beginning with # is treated as a comment in .pgpass. But there was no code doing such special handling. Whether a line begins with # or not, libpq just checked that the first token in the line match with the host. For (1), this commit makes libpq warn if the length of a line is larger than 319B, and throw away the remaining part beginning from 320B position. For (2), this commit changes libpq so that it treats any lines beginning with # as comments. Author: Fujii Masao Reviewed-by: Hamid Akhtar Discussion: https://postgr.es/m/c0f0c01c-fa74-9749-2084-b73882fd5465@oss.nttdata.com
2020-03-05 05:00:38 +01:00
{
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
char *t = buf.data;
int len;
Fix issues around .pgpass file. This commit fixes the following two issues around .pgpass file. (1) If the length of a line in .pgpass file was larger than 319B, libpq silently treated each 319B in the line as a separate setting line. (2) The document explains that a line beginning with # is treated as a comment in .pgpass. But there was no code doing such special handling. Whether a line begins with # or not, libpq just checked that the first token in the line match with the host. For (1), this commit makes libpq warn if the length of a line is larger than 319B, and throw away the remaining part beginning from 320B position. For (2), this commit changes libpq so that it treats any lines beginning with # as comments. Author: Fujii Masao Reviewed-by: Hamid Akhtar Discussion: https://postgr.es/m/c0f0c01c-fa74-9749-2084-b73882fd5465@oss.nttdata.com
2020-03-05 05:00:38 +01:00
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
/* strip trailing newline and carriage return */
len = pg_strip_crlf(t);
Fix issues around .pgpass file. This commit fixes the following two issues around .pgpass file. (1) If the length of a line in .pgpass file was larger than 319B, libpq silently treated each 319B in the line as a separate setting line. (2) The document explains that a line beginning with # is treated as a comment in .pgpass. But there was no code doing such special handling. Whether a line begins with # or not, libpq just checked that the first token in the line match with the host. For (1), this commit makes libpq warn if the length of a line is larger than 319B, and throw away the remaining part beginning from 320B position. For (2), this commit changes libpq so that it treats any lines beginning with # as comments. Author: Fujii Masao Reviewed-by: Hamid Akhtar Discussion: https://postgr.es/m/c0f0c01c-fa74-9749-2084-b73882fd5465@oss.nttdata.com
2020-03-05 05:00:38 +01:00
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
if (len > 0 &&
(t = pwdfMatchesString(t, hostname)) != NULL &&
(t = pwdfMatchesString(t, port)) != NULL &&
(t = pwdfMatchesString(t, dbname)) != NULL &&
(t = pwdfMatchesString(t, username)) != NULL)
Fix issues around .pgpass file. This commit fixes the following two issues around .pgpass file. (1) If the length of a line in .pgpass file was larger than 319B, libpq silently treated each 319B in the line as a separate setting line. (2) The document explains that a line beginning with # is treated as a comment in .pgpass. But there was no code doing such special handling. Whether a line begins with # or not, libpq just checked that the first token in the line match with the host. For (1), this commit makes libpq warn if the length of a line is larger than 319B, and throw away the remaining part beginning from 320B position. For (2), this commit changes libpq so that it treats any lines beginning with # as comments. Author: Fujii Masao Reviewed-by: Hamid Akhtar Discussion: https://postgr.es/m/c0f0c01c-fa74-9749-2084-b73882fd5465@oss.nttdata.com
2020-03-05 05:00:38 +01:00
{
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
/* Found a match. */
char *ret,
*p1,
*p2;
Allow DOS-style line endings in ~/.pgpass files. On Windows, libc will mask \r\n line endings for us, since we read the password file in text mode. But that doesn't happen on Unix. People who share password files across both systems might have \r\n line endings in a file they use on Unix, so as a convenience, ignore trailing \r. Per gripe from Josh Berkus. In passing, put the existing check for empty line somewhere where it's actually useful, ie after stripping the newline not before. Vik Fearing, adjusted a bit by me Discussion: <0de37763-5843-b2cc-855e-5d0e5df25807@agliodbs.com>
2016-11-15 22:17:19 +01:00
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
ret = strdup(t);
Fix regression in .pgpass support. From Neil Conway.
2003-01-30 20:49:54 +01:00
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
fclose(fp);
explicit_bzero(buf.data, buf.maxlen);
termPQExpBuffer(&buf);
Allow DOS-style line endings in ~/.pgpass files. On Windows, libc will mask \r\n line endings for us, since we read the password file in text mode. But that doesn't happen on Unix. People who share password files across both systems might have \r\n line endings in a file they use on Unix, so as a convenience, ignore trailing \r. Per gripe from Josh Berkus. In passing, put the existing check for empty line somewhere where it's actually useful, ie after stripping the newline not before. Vik Fearing, adjusted a bit by me Discussion: <0de37763-5843-b2cc-855e-5d0e5df25807@agliodbs.com>
2016-11-15 22:17:19 +01:00
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
if (!ret)
{
/* Out of memory. XXX: an error message would be nice. */
return NULL;
}
Don't forget to de-escape the password field in .pgpass. This has been broken just about forever (or more specifically, commit 7f4981f4af1700456f98ac3f2b2d84959919ec81) and nobody noticed until Richard Huxton reported it recently. Analysis and fix by Ross Reedstrom, although I didn't use his patch. This doesn't seem important enough to back-patch and is mildly backward incompatible, so I'm just doing this in master.
2011-12-22 18:55:27 +01:00
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
/* De-escape password. */
for (p1 = p2 = ret; *p1 != ':' && *p1 != '\0'; ++p1, ++p2)
{
if (*p1 == '\\' && p1[1] != '\0')
++p1;
*p2 = *p1;
}
*p2 = '\0';
Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions.
2014-11-25 11:55:00 +01:00
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
return ret;
}
Don't forget to de-escape the password field in .pgpass. This has been broken just about forever (or more specifically, commit 7f4981f4af1700456f98ac3f2b2d84959919ec81) and nobody noticed until Richard Huxton reported it recently. Analysis and fix by Ross Reedstrom, although I didn't use his patch. This doesn't seem important enough to back-patch and is mildly backward incompatible, so I'm just doing this in master.
2011-12-22 18:55:27 +01:00
}
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
/* No match, reset buffer to prepare for next line. */
buf.len = 0;
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
}
Remove PGPASSWORDFILE and default to always trying $HOME/.pgpass. Cleanup up memory allocation for $HOME in related psql places. Update mention of $HOME/.pgpass in the docs; add mention in pg_dumpall.
2002-09-06 00:05:50 +02:00
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
fclose(fp);
Teach libpq to handle arbitrary-length lines in .pgpass files. Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-09-01 19:14:44 +02:00
explicit_bzero(buf.data, buf.maxlen);
termPQExpBuffer(&buf);
I'm giving a try at some TODO items. Currently it's the turn of the PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
2002-08-15 04:56:19 +02:00
return NULL;
}
Allow libpq to do thread-safe SIGPIPE handling. This allows it to ignore SIGPIPE from send() in libpq, but terminate on any other SIGPIPE, unless the user installs their own signal handler. This is a minor fix because the only time you get SIGPIPE from libpq's send() is when the backend dies.
2004-01-09 03:02:43 +01:00
Add libpq warning message if the .pgpass-retrieved password fails. Add ERRCODE_INVALID_PASSWORD sqlstate error code.
2010-03-13 15:55:57 +01:00
/*
Avoid improbable null pointer dereference in pgpassfileWarning(). Coverity complained that we might pass a null pointer to strcmp() if PQresultErrorField were to return NULL. That shouldn't be possible, since the server is supposed to always provide some SQLSTATE or other in an error message. But we usually defend against such hazards, and it only takes a little more code to do so here. There's no good reason to think this is a live bug, so no back-patch.
2017-02-03 01:49:15 +01:00
* If the connection failed due to bad password, we should mention
* if we got the password from the pgpassfile.
Add libpq warning message if the .pgpass-retrieved password fails. Add ERRCODE_INVALID_PASSWORD sqlstate error code.
2010-03-13 15:55:57 +01:00
*/
static void
Allow password file name to be specified as a libpq connection parameter. Formerly an alternate password file could only be selected via the environment variable PGPASSFILE; now it can also be selected via a new connection parameter "passfile", corresponding to the conventions for most other connection parameters. There was some concern about this creating a security weakness, but it was agreed that that argument was pretty thin, and there are clear use-cases for handling password files this way. Julian Markwort, reviewed by Fabien Coelho, some adjustments by me Discussion: https://postgr.es/m/a4b4f4f1-7b58-a0e8-5268-5f7db8e8ccaa@uni-muenster.de
2017-01-24 23:06:21 +01:00
pgpassfileWarning(PGconn *conn)
Add libpq warning message if the .pgpass-retrieved password fails. Add ERRCODE_INVALID_PASSWORD sqlstate error code.
2010-03-13 15:55:57 +01:00
{
Allow password file name to be specified as a libpq connection parameter. Formerly an alternate password file could only be selected via the environment variable PGPASSFILE; now it can also be selected via a new connection parameter "passfile", corresponding to the conventions for most other connection parameters. There was some concern about this creating a security weakness, but it was agreed that that argument was pretty thin, and there are clear use-cases for handling password files this way. Julian Markwort, reviewed by Fabien Coelho, some adjustments by me Discussion: https://postgr.es/m/a4b4f4f1-7b58-a0e8-5268-5f7db8e8ccaa@uni-muenster.de
2017-01-24 23:06:21 +01:00
/* If it was 'invalid authorization', add pgpassfile mention */
Add libpq warning message if the .pgpass-retrieved password fails. Add ERRCODE_INVALID_PASSWORD sqlstate error code.
2010-03-13 15:55:57 +01:00
/* only works with >= 9.0 servers */
Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
2018-08-06 16:53:35 +02:00
if (conn->password_needed &&
conn->connhost[conn->whichhost].password != NULL &&
conn->result)
Add libpq warning message if the .pgpass-retrieved password fails. Add ERRCODE_INVALID_PASSWORD sqlstate error code.
2010-03-13 15:55:57 +01:00
{
Avoid improbable null pointer dereference in pgpassfileWarning(). Coverity complained that we might pass a null pointer to strcmp() if PQresultErrorField were to return NULL. That shouldn't be possible, since the server is supposed to always provide some SQLSTATE or other in an error message. But we usually defend against such hazards, and it only takes a little more code to do so here. There's no good reason to think this is a live bug, so no back-patch.
2017-02-03 01:49:15 +01:00
const char *sqlstate = PQresultErrorField(conn->result,
PG_DIAG_SQLSTATE);
if (sqlstate && strcmp(sqlstate, ERRCODE_INVALID_PASSWORD) == 0)
appendPQExpBuffer(&conn->errorMessage,
Fix peculiar, untranslatable message concatenation attempt
2010-03-17 21:58:38 +01:00
libpq_gettext("password retrieved from file \"%s\"\n"),
Avoid improbable null pointer dereference in pgpassfileWarning(). Coverity complained that we might pass a null pointer to strcmp() if PQresultErrorField were to return NULL. That shouldn't be possible, since the server is supposed to always provide some SQLSTATE or other in an error message. But we usually defend against such hazards, and it only takes a little more code to do so here. There's no good reason to think this is a live bug, so no back-patch.
2017-02-03 01:49:15 +01:00
conn->pgpassfile);
Add libpq warning message if the .pgpass-retrieved password fails. Add ERRCODE_INVALID_PASSWORD sqlstate error code.
2010-03-13 15:55:57 +01:00
}
}
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
/*
Fix some grammar and typos in comments and docs The documentation fixes are backpatched down to where they apply. Author: Justin Pryzby Discussion: https://postgr.es/m/20201031020801.GD3080@telsasoft.com Backpatch-through: 9.6
2020-11-02 07:14:41 +01:00
* Check if the SSL protocol value given in input is valid or not.
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
* This is used as a sanity check routine for the connection parameters
Rename connection parameters to control min/max SSL protocol version in libpq The libpq parameters ssl{max|min}protocolversion are renamed to use underscores, to become ssl_{max|min}_protocol_version. The related environment variables still use the names introduced in commit ff8ca5f that added the feature. Per complaint from Peter Eisentraut (this was also mentioned by me in the original patch review but the issue got discarded). Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com
2020-04-30 06:39:10 +02:00
* ssl_min_protocol_version and ssl_max_protocol_version.
Add connection parameters to control SSL protocol min/max in libpq These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-28 02:40:48 +01:00
*/
static bool
sslVerifyProtocolVersion(const char *version)
{
/*
* An empty string and a NULL value are considered valid as it is
* equivalent to ignoring the parameter.
*/
if (!version || strlen(version) == 0)
return true;
if (pg_strcasecmp(version, "TLSv1") == 0 ||
pg_strcasecmp(version, "TLSv1.1") == 0 ||
pg_strcasecmp(version, "TLSv1.2") == 0 ||
pg_strcasecmp(version, "TLSv1.3") == 0)
return true;
/* anything else is wrong */
return false;
}
/*
* Ensure that the SSL protocol range given in input is correct. The check
* is performed on the input string to keep it TLS backend agnostic. Input
* to this function is expected verified with sslVerifyProtocolVersion().
*/
static bool
sslVerifyProtocolRange(const char *min, const char *max)
{
Assert(sslVerifyProtocolVersion(min) &&
sslVerifyProtocolVersion(max));
/* If at least one of the bounds is not set, the range is valid */
if (min == NULL || max == NULL || strlen(min) == 0 || strlen(max) == 0)
return true;
/*
* If the minimum version is the lowest one we accept, then all options
* for the maximum are valid.
*/
if (pg_strcasecmp(min, "TLSv1") == 0)
return true;
/*
* The minimum bound is valid, and cannot be TLSv1, so using TLSv1 for the
* maximum is incorrect.
*/
if (pg_strcasecmp(max, "TLSv1") == 0)
return false;
/*
* At this point we know that we have a mix of TLSv1.1 through 1.3
* versions.
*/
if (pg_strcasecmp(min, max) > 0)
return false;
return true;
}
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Make the various places that determine the user's "home directory" consistent. On Unix we now always consult getpwuid(); $HOME isn't used at all. On Windows the code currently consults $USERPROFILE, or $HOME if that's not defined, but I expect this will change as soon as the win32 hackers come to a consensus. Nothing done yet about changing the file names used underneath $USERPROFILE.
2005-01-06 02:00:12 +01:00
/*
* Obtain user's home directory, return in given buffer
*
Adjust lookup of client-side profile files (.pgpass and so on) as per discussion on pgsql-hackers-win32 list. Documentation still needs to be tweaked --- I'm not sure how to refer to the APPDATA folder in user documentation.
2005-01-06 19:29:11 +01:00
* On Unix, this actually returns the user's home directory. On Windows
* it returns the PostgreSQL-specific application data folder.
*
Make the various places that determine the user's "home directory" consistent. On Unix we now always consult getpwuid(); $HOME isn't used at all. On Windows the code currently consults $USERPROFILE, or $HOME if that's not defined, but I expect this will change as soon as the win32 hackers come to a consensus. Nothing done yet about changing the file names used underneath $USERPROFILE.
2005-01-06 02:00:12 +01:00
* This is essentially the same as get_home_path(), but we don't use that
* because we don't want to pull path.c into libpq (it pollutes application
Fix libpq to not require user's home directory to exist. Some people like to run libpq-using applications in environments where there's no home directory. We've broken that scenario before (cf commits 5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making it a hard error if we fail to get the home directory name while looking for ~/.pgpass. The previous precedent is that if we can't get the home directory name, we should just silently act as though the file we hoped to find there doesn't exist. Rearrange the new code to honor that. Looking around, the service-file code added by commit 41a4e4595 had the same disease. Apparently, that escaped notice because it only runs when a service name has been specified, which I guess the people who use this scenario don't do. Nonetheless, it's wrong too, so fix that case as well. Add a comment about this policy to pqGetHomeDirectory, in the probably vain hope of forestalling the same error in future. And upgrade the rather miserable commenting in parseServiceInfo, too. In passing, also back off parseServiceInfo's assumption that only ENOENT is an ignorable error from stat() when checking a service file. We would need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that the far-better-tested code for ~/.pgpass treats all stat() failures alike, I think this code ought to as well. Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10 where ba005f193 came in. The service-file bugs are far older, so back-patch the other changes to all supported branches. Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
* namespace).
*
* Returns true on success, false on failure to obtain the directory name.
*
* CAUTION: although in most situations failure is unexpected, there are users
* who like to run applications in a home-directory-less environment. On
* failure, you almost certainly DO NOT want to report an error. Just act as
* though whatever file you were hoping to find in the home directory isn't
* there (which it isn't).
Make the various places that determine the user's "home directory" consistent. On Unix we now always consult getpwuid(); $HOME isn't used at all. On Windows the code currently consults $USERPROFILE, or $HOME if that's not defined, but I expect this will change as soon as the win32 hackers come to a consensus. Nothing done yet about changing the file names used underneath $USERPROFILE.
2005-01-06 02:00:12 +01:00
*/
bool
pqGetHomeDirectory(char *buf, int bufsize)
{
#ifndef WIN32
Prefer $HOME when looking up the current user's home directory. When we need to identify the home directory on non-Windows, first consult getenv("HOME"). If that's empty or unset, fall back on our previous method of checking the <pwd.h> database. Preferring $HOME allows the user to intentionally point at some other directory, and it seems to be in line with the behavior of most other utilities. However, we shouldn't rely on it completely, as $HOME is likely to be unset when running as a daemon. Anders Kaseorg Discussion: https://postgr.es/m/1634252654444.90107@mit.edu
2022-01-10 01:19:02 +01:00
const char *home;
Make the various places that determine the user's "home directory" consistent. On Unix we now always consult getpwuid(); $HOME isn't used at all. On Windows the code currently consults $USERPROFILE, or $HOME if that's not defined, but I expect this will change as soon as the win32 hackers come to a consensus. Nothing done yet about changing the file names used underneath $USERPROFILE.
2005-01-06 02:00:12 +01:00
Prefer $HOME when looking up the current user's home directory. When we need to identify the home directory on non-Windows, first consult getenv("HOME"). If that's empty or unset, fall back on our previous method of checking the <pwd.h> database. Preferring $HOME allows the user to intentionally point at some other directory, and it seems to be in line with the behavior of most other utilities. However, we shouldn't rely on it completely, as $HOME is likely to be unset when running as a daemon. Anders Kaseorg Discussion: https://postgr.es/m/1634252654444.90107@mit.edu
2022-01-10 01:19:02 +01:00
home = getenv("HOME");
if (home == NULL || home[0] == '\0')
Clean up messy API for src/port/thread.c. The point of this patch is to reduce inclusion spam by not needing to #include <netdb.h> or <pwd.h> in port.h (which is read by every compile in our tree). To do that, we must remove port.h's declarations of pqGetpwuid and pqGethostbyname. pqGethostbyname is only used, and is only ever likely to be used, in src/port/getaddrinfo.c --- which isn't even built on most platforms, making pqGethostbyname dead code for most people. Hence, deal with that by just moving it into getaddrinfo.c. To clean up pqGetpwuid, invent a couple of simple wrapper functions with less-messy APIs. This allows removing some duplicate error-handling code, too. In passing, remove thread.c from the MSVC build, since it contains nothing we use on Windows. Noted while working on 376ce3e40. Discussion: https://postgr.es/m/1634252654444.90107@mit.edu
2022-01-11 19:46:12 +01:00
return pg_get_user_home_dir(geteuid(), buf, bufsize);
Prefer $HOME when looking up the current user's home directory. When we need to identify the home directory on non-Windows, first consult getenv("HOME"). If that's empty or unset, fall back on our previous method of checking the <pwd.h> database. Preferring $HOME allows the user to intentionally point at some other directory, and it seems to be in line with the behavior of most other utilities. However, we shouldn't rely on it completely, as $HOME is likely to be unset when running as a daemon. Anders Kaseorg Discussion: https://postgr.es/m/1634252654444.90107@mit.edu
2022-01-10 01:19:02 +01:00
strlcpy(buf, home, bufsize);
Make the various places that determine the user's "home directory" consistent. On Unix we now always consult getpwuid(); $HOME isn't used at all. On Windows the code currently consults $USERPROFILE, or $HOME if that's not defined, but I expect this will change as soon as the win32 hackers come to a consensus. Nothing done yet about changing the file names used underneath $USERPROFILE.
2005-01-06 02:00:12 +01:00
return true;
#else
Adjust lookup of client-side profile files (.pgpass and so on) as per discussion on pgsql-hackers-win32 list. Documentation still needs to be tweaked --- I'm not sure how to refer to the APPDATA folder in user documentation.
2005-01-06 19:29:11 +01:00
char tmppath[MAX_PATH];
Make the various places that determine the user's "home directory" consistent. On Unix we now always consult getpwuid(); $HOME isn't used at all. On Windows the code currently consults $USERPROFILE, or $HOME if that's not defined, but I expect this will change as soon as the win32 hackers come to a consensus. Nothing done yet about changing the file names used underneath $USERPROFILE.
2005-01-06 02:00:12 +01:00
Adjust lookup of client-side profile files (.pgpass and so on) as per discussion on pgsql-hackers-win32 list. Documentation still needs to be tweaked --- I'm not sure how to refer to the APPDATA folder in user documentation.
2005-01-06 19:29:11 +01:00
ZeroMemory(tmppath, sizeof(tmppath));
Use SHGetFolderPath instead of SHGetSpecialFolderPath to find the APPDATA directory on Windows. Magnus Hagander
2005-01-26 20:24:03 +01:00
if (SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, tmppath) != S_OK)
Make the various places that determine the user's "home directory" consistent. On Unix we now always consult getpwuid(); $HOME isn't used at all. On Windows the code currently consults $USERPROFILE, or $HOME if that's not defined, but I expect this will change as soon as the win32 hackers come to a consensus. Nothing done yet about changing the file names used underneath $USERPROFILE.
2005-01-06 02:00:12 +01:00
return false;
Adjust lookup of client-side profile files (.pgpass and so on) as per discussion on pgsql-hackers-win32 list. Documentation still needs to be tweaked --- I'm not sure how to refer to the APPDATA folder in user documentation.
2005-01-06 19:29:11 +01:00
snprintf(buf, bufsize, "%s/postgresql", tmppath);
Make the various places that determine the user's "home directory" consistent. On Unix we now always consult getpwuid(); $HOME isn't used at all. On Windows the code currently consults $USERPROFILE, or $HOME if that's not defined, but I expect this will change as soon as the win32 hackers come to a consensus. Nothing done yet about changing the file names used underneath $USERPROFILE.
2005-01-06 02:00:12 +01:00
return true;
#endif
}
Add thread locking to SSL and Kerberos connections. I have removed the docs mentioning that SSL and Kerberos are not thread-safe. Manfred Spraul
2004-03-24 04:45:00 +01:00
/*
* To keep the API consistent, the locking stubs are always provided, even
* if they are not required.
Remove libpq's use of abort(3) to handle mutex failure cases. Doing an abort() seems all right in development builds, but not in production builds of general-purpose libraries. However, the functions that were doing this lack any way to report a failure back up to their callers. It seems like we can just get away with ignoring failures in production builds, since (a) no such failures have been reported in the dozen years that the code's been like this, and (b) failure to enforce mutual exclusion during fe-auth.c operations would likely not cause any problems anyway in most cases. (The OpenSSL callbacks that use this macro are obsolete, so even less likely to cause interesting problems.) Possibly a better answer would be to break compatibility of the pgthreadlock_t callback API, but in the absence of field problem reports, it doesn't really seem worth the trouble. Discussion: https://postgr.es/m/3131385.1624746109@sss.pgh.pa.us
2021-06-29 17:31:08 +02:00
*
* Since we neglected to provide any error-return convention in the
* pgthreadlock_t API, we can't do much except Assert upon failure of any
* mutex primitive. Fortunately, such failures appear to be nonexistent in
* the field.
Add thread locking to SSL and Kerberos connections. I have removed the docs mentioning that SSL and Kerberos are not thread-safe. Manfred Spraul
2004-03-24 04:45:00 +01:00
*/
static void
default_threadlock(int acquire)
{
#ifdef ENABLE_THREAD_SAFETY
Enable thread safety for win32.mak build of PostgreSQL. Andreas Pflug
2004-06-19 06:22:17 +02:00
#ifndef WIN32
Add thread locking to SSL and Kerberos connections. I have removed the docs mentioning that SSL and Kerberos are not thread-safe. Manfred Spraul
2004-03-24 04:45:00 +01:00
static pthread_mutex_t singlethread_lock = PTHREAD_MUTEX_INITIALIZER;
Enable thread safety for win32.mak build of PostgreSQL. Andreas Pflug
2004-06-19 06:22:17 +02:00
#else
> win32 doesn't support a static initializer for mutexes, thus the first > user must initialize the lock. The problem are concurrent "first" users > - the pthread_mutex_t initialization must be synchronized. > The current implementation is broken, the attached patches fixes that: > mutex_initlock is a spinlock. If the pthread_mutex_t mutex is not > initialized, then the spinlock is acquired, if the pthread_mutex_t is > initialized if it's not yet initialized and then the spinlock is dropped. Manfred Spraul
2004-07-12 16:23:28 +02:00
static pthread_mutex_t singlethread_lock = NULL;
static long mutex_initlock = 0;
if (singlethread_lock == NULL)
{
while (InterlockedExchange(&mutex_initlock, 1) == 1)
/* loop, another thread own the lock */ ;
if (singlethread_lock == NULL)
Implement error checking for pthreads calls in thread-safe mode. They really should always succeed, but in the likely event of a failure we would previously fall through *without locking* - the new code will exit(1). Printing the error message on stderr will not work for all applications, but it's better than nothing at all - and our API doesn't provide a way to return the error to the caller.
2008-05-16 20:30:53 +02:00
{
if (pthread_mutex_init(&singlethread_lock, NULL))
Remove libpq's use of abort(3) to handle mutex failure cases. Doing an abort() seems all right in development builds, but not in production builds of general-purpose libraries. However, the functions that were doing this lack any way to report a failure back up to their callers. It seems like we can just get away with ignoring failures in production builds, since (a) no such failures have been reported in the dozen years that the code's been like this, and (b) failure to enforce mutual exclusion during fe-auth.c operations would likely not cause any problems anyway in most cases. (The OpenSSL callbacks that use this macro are obsolete, so even less likely to cause interesting problems.) Possibly a better answer would be to break compatibility of the pgthreadlock_t callback API, but in the absence of field problem reports, it doesn't really seem worth the trouble. Discussion: https://postgr.es/m/3131385.1624746109@sss.pgh.pa.us
2021-06-29 17:31:08 +02:00
Assert(false);
Implement error checking for pthreads calls in thread-safe mode. They really should always succeed, but in the likely event of a failure we would previously fall through *without locking* - the new code will exit(1). Printing the error message on stderr will not work for all applications, but it's better than nothing at all - and our API doesn't provide a way to return the error to the caller.
2008-05-16 20:30:53 +02:00
}
> win32 doesn't support a static initializer for mutexes, thus the first > user must initialize the lock. The problem are concurrent "first" users > - the pthread_mutex_t initialization must be synchronized. > The current implementation is broken, the attached patches fixes that: > mutex_initlock is a spinlock. If the pthread_mutex_t mutex is not > initialized, then the spinlock is acquired, if the pthread_mutex_t is > initialized if it's not yet initialized and then the spinlock is dropped. Manfred Spraul
2004-07-12 16:23:28 +02:00
InterlockedExchange(&mutex_initlock, 0);
}
Enable thread safety for win32.mak build of PostgreSQL. Andreas Pflug
2004-06-19 06:22:17 +02:00
#endif
Add thread locking to SSL and Kerberos connections. I have removed the docs mentioning that SSL and Kerberos are not thread-safe. Manfred Spraul
2004-03-24 04:45:00 +01:00
if (acquire)
Implement error checking for pthreads calls in thread-safe mode. They really should always succeed, but in the likely event of a failure we would previously fall through *without locking* - the new code will exit(1). Printing the error message on stderr will not work for all applications, but it's better than nothing at all - and our API doesn't provide a way to return the error to the caller.
2008-05-16 20:30:53 +02:00
{
if (pthread_mutex_lock(&singlethread_lock))
Remove libpq's use of abort(3) to handle mutex failure cases. Doing an abort() seems all right in development builds, but not in production builds of general-purpose libraries. However, the functions that were doing this lack any way to report a failure back up to their callers. It seems like we can just get away with ignoring failures in production builds, since (a) no such failures have been reported in the dozen years that the code's been like this, and (b) failure to enforce mutual exclusion during fe-auth.c operations would likely not cause any problems anyway in most cases. (The OpenSSL callbacks that use this macro are obsolete, so even less likely to cause interesting problems.) Possibly a better answer would be to break compatibility of the pgthreadlock_t callback API, but in the absence of field problem reports, it doesn't really seem worth the trouble. Discussion: https://postgr.es/m/3131385.1624746109@sss.pgh.pa.us
2021-06-29 17:31:08 +02:00
Assert(false);
Implement error checking for pthreads calls in thread-safe mode. They really should always succeed, but in the likely event of a failure we would previously fall through *without locking* - the new code will exit(1). Printing the error message on stderr will not work for all applications, but it's better than nothing at all - and our API doesn't provide a way to return the error to the caller.
2008-05-16 20:30:53 +02:00
}
Add thread locking to SSL and Kerberos connections. I have removed the docs mentioning that SSL and Kerberos are not thread-safe. Manfred Spraul
2004-03-24 04:45:00 +01:00
else
Implement error checking for pthreads calls in thread-safe mode. They really should always succeed, but in the likely event of a failure we would previously fall through *without locking* - the new code will exit(1). Printing the error message on stderr will not work for all applications, but it's better than nothing at all - and our API doesn't provide a way to return the error to the caller.
2008-05-16 20:30:53 +02:00
{
if (pthread_mutex_unlock(&singlethread_lock))
Remove libpq's use of abort(3) to handle mutex failure cases. Doing an abort() seems all right in development builds, but not in production builds of general-purpose libraries. However, the functions that were doing this lack any way to report a failure back up to their callers. It seems like we can just get away with ignoring failures in production builds, since (a) no such failures have been reported in the dozen years that the code's been like this, and (b) failure to enforce mutual exclusion during fe-auth.c operations would likely not cause any problems anyway in most cases. (The OpenSSL callbacks that use this macro are obsolete, so even less likely to cause interesting problems.) Possibly a better answer would be to break compatibility of the pgthreadlock_t callback API, but in the absence of field problem reports, it doesn't really seem worth the trouble. Discussion: https://postgr.es/m/3131385.1624746109@sss.pgh.pa.us
2021-06-29 17:31:08 +02:00
Assert(false);
Implement error checking for pthreads calls in thread-safe mode. They really should always succeed, but in the likely event of a failure we would previously fall through *without locking* - the new code will exit(1). Printing the error message on stderr will not work for all applications, but it's better than nothing at all - and our API doesn't provide a way to return the error to the caller.
2008-05-16 20:30:53 +02:00
}
Add thread locking to SSL and Kerberos connections. I have removed the docs mentioning that SSL and Kerberos are not thread-safe. Manfred Spraul
2004-03-24 04:45:00 +01:00
#endif
}
Code review for recent libpq changes. Be more careful about error handling in SIGPIPE processing; avoid unnecessary pollution of application link-symbol namespace; spell 'pointer to function' in the conventional way.
2004-12-03 00:20:21 +01:00
pgthreadlock_t
PQregisterThreadLock(pgthreadlock_t newhandler)
Add thread locking to SSL and Kerberos connections. I have removed the docs mentioning that SSL and Kerberos are not thread-safe. Manfred Spraul
2004-03-24 04:45:00 +01:00
{
Code review for recent libpq changes. Be more careful about error handling in SIGPIPE processing; avoid unnecessary pollution of application link-symbol namespace; spell 'pointer to function' in the conventional way.
2004-12-03 00:20:21 +01:00
pgthreadlock_t prev = pg_g_threadlock;
Add thread locking to SSL and Kerberos connections. I have removed the docs mentioning that SSL and Kerberos are not thread-safe. Manfred Spraul
2004-03-24 04:45:00 +01:00
if (newhandler)
Code review for recent libpq changes. Be more careful about error handling in SIGPIPE processing; avoid unnecessary pollution of application link-symbol namespace; spell 'pointer to function' in the conventional way.
2004-12-03 00:20:21 +01:00
pg_g_threadlock = newhandler;
Add thread locking to SSL and Kerberos connections. I have removed the docs mentioning that SSL and Kerberos are not thread-safe. Manfred Spraul
2004-03-24 04:45:00 +01:00
else
Code review for recent libpq changes. Be more careful about error handling in SIGPIPE processing; avoid unnecessary pollution of application link-symbol namespace; spell 'pointer to function' in the conventional way.
2004-12-03 00:20:21 +01:00
pg_g_threadlock = default_threadlock;
Add thread locking to SSL and Kerberos connections. I have removed the docs mentioning that SSL and Kerberos are not thread-safe. Manfred Spraul
2004-03-24 04:45:00 +01:00
return prev;
}