1998-08-17 05:52:36 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* libpq-int.h
|
1998-08-17 05:52:36 +02:00
|
|
|
* This file contains internal definitions meant to be used only by
|
|
|
|
* the frontend libpq library, not by applications that call it.
|
|
|
|
*
|
1998-09-03 04:10:56 +02:00
|
|
|
* An application can include this file if it wants to bypass the
|
|
|
|
* official API defined by libpq-fe.h, but code that does so is much
|
|
|
|
* more likely to break across PostgreSQL releases than code that uses
|
|
|
|
* only the official API.
|
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1998-08-17 05:52:36 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/interfaces/libpq/libpq-int.h
|
1998-08-17 05:52:36 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef LIBPQ_INT_H
|
|
|
|
#define LIBPQ_INT_H
|
|
|
|
|
2003-06-21 23:51:35 +02:00
|
|
|
/* We assume libpq-fe.h has already been included. */
|
2008-09-17 06:31:08 +02:00
|
|
|
#include "libpq-events.h"
|
2003-06-21 23:51:35 +02:00
|
|
|
|
2022-08-13 23:53:28 +02:00
|
|
|
#include <netdb.h>
|
|
|
|
#include <sys/socket.h>
|
2002-08-18 03:35:40 +02:00
|
|
|
#include <time.h>
|
2023-03-29 21:53:38 +02:00
|
|
|
/* MinGW has sys/time.h, but MSVC doesn't */
|
|
|
|
#ifndef _MSC_VER
|
2002-10-03 19:09:42 +02:00
|
|
|
#include <sys/time.h>
|
|
|
|
#endif
|
2002-08-18 03:35:40 +02:00
|
|
|
|
2005-08-23 23:02:05 +02:00
|
|
|
#ifdef WIN32
|
|
|
|
#include "pthread-win32.h"
|
|
|
|
#else
|
2004-01-09 03:02:43 +01:00
|
|
|
#include <pthread.h>
|
2005-08-23 23:02:05 +02:00
|
|
|
#endif
|
2004-12-02 16:32:54 +01:00
|
|
|
#include <signal.h>
|
2003-06-14 19:49:54 +02:00
|
|
|
|
1999-08-31 03:37:37 +02:00
|
|
|
/* include stuff common to fe and be */
|
1998-08-17 05:52:36 +02:00
|
|
|
#include "libpq/pqcomm.h"
|
1999-08-31 03:37:37 +02:00
|
|
|
/* include stuff found in fe only */
|
2021-07-07 03:55:15 +02:00
|
|
|
#include "fe-auth-sasl.h"
|
1999-08-31 03:37:37 +02:00
|
|
|
#include "pqexpbuffer.h"
|
|
|
|
|
2007-07-10 15:14:22 +02:00
|
|
|
#ifdef ENABLE_GSS
|
2007-07-12 16:36:52 +02:00
|
|
|
#if defined(HAVE_GSSAPI_H)
|
|
|
|
#include <gssapi.h>
|
|
|
|
#else
|
2007-07-10 15:14:22 +02:00
|
|
|
#include <gssapi/gssapi.h>
|
|
|
|
#endif
|
2007-07-12 16:36:52 +02:00
|
|
|
#endif
|
2007-07-10 15:14:22 +02:00
|
|
|
|
2007-07-23 12:16:54 +02:00
|
|
|
#ifdef ENABLE_SSPI
|
|
|
|
#define SECURITY_WIN32
|
2017-04-11 15:21:25 +02:00
|
|
|
#if defined(WIN32) && !defined(_MSC_VER)
|
2009-04-20 00:37:13 +02:00
|
|
|
#include <ntsecapi.h>
|
|
|
|
#endif
|
2007-07-23 12:16:54 +02:00
|
|
|
#include <security.h>
|
|
|
|
#undef SECURITY_WIN32
|
|
|
|
|
|
|
|
#ifndef ENABLE_GSS
|
|
|
|
/*
|
|
|
|
* Define a fake structure compatible with GSSAPI on Unix.
|
|
|
|
*/
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
void *value;
|
|
|
|
int length;
|
|
|
|
} gss_buffer_desc;
|
|
|
|
#endif
|
|
|
|
#endif /* ENABLE_SSPI */
|
|
|
|
|
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
|
|
|
#ifdef USE_OPENSSL
|
2000-01-14 06:33:15 +01:00
|
|
|
#include <openssl/ssl.h>
|
|
|
|
#include <openssl/err.h>
|
2009-06-23 20:13:23 +02:00
|
|
|
|
2016-08-29 19:16:02 +02:00
|
|
|
#ifndef OPENSSL_NO_ENGINE
|
2009-06-23 20:13:23 +02:00
|
|
|
#define USE_SSL_ENGINE
|
1999-09-27 05:13:16 +02:00
|
|
|
#endif
|
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
|
|
|
#endif /* USE_OPENSSL */
|
2009-06-23 20:13:23 +02:00
|
|
|
|
2023-03-29 21:53:38 +02:00
|
|
|
#include "common/pg_prng.h"
|
|
|
|
|
1998-09-03 04:10:56 +02:00
|
|
|
/*
|
|
|
|
* POSTGRES backend dependent Constants.
|
|
|
|
*/
|
2007-07-23 20:59:50 +02:00
|
|
|
#define CMDSTATUS_LEN 64 /* should match COMPLETION_TAG_BUFSIZE */
|
1998-09-03 04:10:56 +02:00
|
|
|
|
1998-11-18 01:47:28 +01:00
|
|
|
/*
|
|
|
|
* PGresult and the subsidiary types PGresAttDesc, PGresAttValue
|
1998-09-03 04:10:56 +02:00
|
|
|
* represent the result of a query (or more precisely, of a single SQL
|
|
|
|
* command --- a query string given to PQexec can contain multiple commands).
|
|
|
|
* Note we assume that a single command can return at most one tuple group,
|
|
|
|
* hence there is no need for multiple descriptor sets.
|
|
|
|
*/
|
1998-11-18 01:47:28 +01:00
|
|
|
|
|
|
|
/* Subsidiary-storage management structure for PGresult.
|
|
|
|
* See space management routines in fe-exec.c for details.
|
|
|
|
* Note that space[k] refers to the k'th byte starting from the physical
|
2000-01-14 06:33:15 +01:00
|
|
|
* head of the block --- it's a union, not a struct!
|
1998-11-18 01:47:28 +01:00
|
|
|
*/
|
|
|
|
typedef union pgresult_data PGresult_data;
|
|
|
|
|
|
|
|
union pgresult_data
|
|
|
|
{
|
|
|
|
PGresult_data *next; /* link to next block, or NULL */
|
|
|
|
char space[1]; /* dummy for accessing block as bytes */
|
|
|
|
};
|
|
|
|
|
2006-08-18 21:52:39 +02:00
|
|
|
/* Data about a single parameter of a prepared statement */
|
|
|
|
typedef struct pgresParamDesc
|
|
|
|
{
|
|
|
|
Oid typid; /* type id */
|
|
|
|
} PGresParamDesc;
|
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/*
|
|
|
|
* Data for a single attribute of a single tuple
|
|
|
|
*
|
|
|
|
* We use char* for Attribute values.
|
|
|
|
*
|
|
|
|
* The value pointer always points to a null-terminated area; we add a
|
|
|
|
* null (zero) byte after whatever the backend sends us. This is only
|
2003-06-21 23:51:35 +02:00
|
|
|
* particularly useful for text values ... with a binary value, the
|
2003-06-08 19:43:00 +02:00
|
|
|
* value might have embedded nulls, so the application can't use C string
|
|
|
|
* operators on it. But we add a null anyway for consistency.
|
|
|
|
* Note that the value itself does not contain a length word.
|
|
|
|
*
|
|
|
|
* A NULL attribute is a special case in two ways: its len field is NULL_LEN
|
|
|
|
* and its value field points to null_field in the owning PGresult. All the
|
|
|
|
* NULL attributes in a query result point to the same place (there's no need
|
|
|
|
* to store a null string separately for each one).
|
1998-09-03 04:10:56 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
#define NULL_LEN (-1) /* pg_result len for NULL value */
|
|
|
|
|
|
|
|
typedef struct pgresAttValue
|
|
|
|
{
|
|
|
|
int len; /* length in bytes of the value */
|
1998-11-18 01:47:28 +01:00
|
|
|
char *value; /* actual value, plus terminating zero byte */
|
1998-09-03 04:10:56 +02:00
|
|
|
} PGresAttValue;
|
1999-05-25 18:15:34 +02:00
|
|
|
|
2003-06-21 23:51:35 +02:00
|
|
|
/* Typedef for message-field list entries */
|
|
|
|
typedef struct pgMessageField
|
|
|
|
{
|
|
|
|
struct pgMessageField *next; /* list link */
|
|
|
|
char code; /* field code */
|
2015-02-21 07:46:43 +01:00
|
|
|
char contents[FLEXIBLE_ARRAY_MEMBER]; /* value, nul-terminated */
|
2003-06-21 23:51:35 +02:00
|
|
|
} PGMessageField;
|
|
|
|
|
|
|
|
/* Fields needed for notice handling */
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
PQnoticeReceiver noticeRec; /* notice message receiver */
|
|
|
|
void *noticeRecArg;
|
|
|
|
PQnoticeProcessor noticeProc; /* notice message processor */
|
|
|
|
void *noticeProcArg;
|
|
|
|
} PGNoticeHooks;
|
|
|
|
|
2008-09-17 06:31:08 +02:00
|
|
|
typedef struct PGEvent
|
|
|
|
{
|
|
|
|
PGEventProc proc; /* the function to call on events */
|
|
|
|
char *name; /* used only for error messages */
|
|
|
|
void *passThrough; /* pointer supplied at registration time */
|
|
|
|
void *data; /* optional state (instance) data */
|
2008-09-19 18:40:40 +02:00
|
|
|
bool resultInitialized; /* T if RESULTCREATE/COPY succeeded */
|
2008-09-17 06:31:08 +02:00
|
|
|
} PGEvent;
|
|
|
|
|
1998-10-01 03:40:26 +02:00
|
|
|
struct pg_result
|
1998-09-03 04:10:56 +02:00
|
|
|
{
|
|
|
|
int ntups;
|
|
|
|
int numAttributes;
|
|
|
|
PGresAttDesc *attDescs;
|
2019-08-05 05:14:58 +02:00
|
|
|
PGresAttValue **tuples; /* each PGresult tuple is an array of
|
1998-09-03 04:10:56 +02:00
|
|
|
* PGresAttValue's */
|
2003-06-21 23:51:35 +02:00
|
|
|
int tupArrSize; /* allocated size of tuples array */
|
2006-08-18 21:52:39 +02:00
|
|
|
int numParameters;
|
|
|
|
PGresParamDesc *paramDescs;
|
1998-09-03 04:10:56 +02:00
|
|
|
ExecStatusType resultStatus;
|
|
|
|
char cmdStatus[CMDSTATUS_LEN]; /* cmd status from the query */
|
|
|
|
int binary; /* binary tuple values if binary == 1,
|
2003-04-24 23:16:45 +02:00
|
|
|
* otherwise text */
|
2000-04-12 19:17:23 +02:00
|
|
|
|
2000-03-15 00:59:23 +01:00
|
|
|
/*
|
|
|
|
* These fields are copied from the originating PGconn, so that operations
|
|
|
|
* on the PGresult don't have to reference the PGconn.
|
2000-03-11 04:08:37 +01:00
|
|
|
*/
|
2003-06-21 23:51:35 +02:00
|
|
|
PGNoticeHooks noticeHooks;
|
2008-09-17 06:31:08 +02:00
|
|
|
PGEvent *events;
|
|
|
|
int nEvents;
|
2000-03-15 00:59:23 +01:00
|
|
|
int client_encoding; /* encoding id */
|
|
|
|
|
2003-04-24 23:16:45 +02:00
|
|
|
/*
|
|
|
|
* Error information (all NULL if not an error result). errMsg is the
|
|
|
|
* "overall" error message returned by PQresultErrorMessage. If we have
|
2003-06-21 23:51:35 +02:00
|
|
|
* per-field info then it is stored in a linked list.
|
2003-04-24 23:16:45 +02:00
|
|
|
*/
|
1998-10-01 03:40:26 +02:00
|
|
|
char *errMsg; /* error message, or NULL if no error */
|
2003-06-21 23:51:35 +02:00
|
|
|
PGMessageField *errFields; /* message broken into fields */
|
2016-04-03 18:24:54 +02:00
|
|
|
char *errQuery; /* text of triggering query, if available */
|
2003-04-24 23:16:45 +02:00
|
|
|
|
1998-11-18 01:47:28 +01:00
|
|
|
/* All NULL attributes in the query result point to this null string */
|
|
|
|
char null_field[1];
|
1999-05-25 18:15:34 +02:00
|
|
|
|
1998-11-18 01:47:28 +01:00
|
|
|
/*
|
2003-06-21 23:51:35 +02:00
|
|
|
* Space management information. Note that attDescs and error stuff, if
|
|
|
|
* not null, point into allocated blocks. But tuples points to a
|
1998-11-18 01:47:28 +01:00
|
|
|
* separately malloc'd block, so that we can realloc it.
|
|
|
|
*/
|
|
|
|
PGresult_data *curBlock; /* most recently allocated block */
|
|
|
|
int curOffset; /* start offset of free space in block */
|
|
|
|
int spaceLeft; /* number of free bytes remaining in block */
|
2018-09-12 00:45:02 +02:00
|
|
|
|
|
|
|
size_t memorySize; /* total space allocated for this PGresult */
|
1998-09-03 04:10:56 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
/* PGAsyncStatusType defines the state of the query-execution state machine */
|
|
|
|
typedef enum
|
|
|
|
{
|
|
|
|
PGASYNC_IDLE, /* nothing's happening, dude */
|
|
|
|
PGASYNC_BUSY, /* query in progress */
|
2021-03-15 22:13:42 +01:00
|
|
|
PGASYNC_READY, /* query done, waiting for client to fetch
|
|
|
|
* result */
|
|
|
|
PGASYNC_READY_MORE, /* query done, waiting for client to fetch
|
|
|
|
* result, more results expected from this
|
|
|
|
* query */
|
1998-09-03 04:10:56 +02:00
|
|
|
PGASYNC_COPY_IN, /* Copy In data transfer in progress */
|
2010-12-11 15:27:37 +01:00
|
|
|
PGASYNC_COPY_OUT, /* Copy Out data transfer in progress */
|
libpq: Improve idle state handling in pipeline mode
We were going into IDLE state too soon when executing queries via
PQsendQuery in pipeline mode, causing several scenarios to misbehave in
different ways -- most notably, as reported by Daniele Varrazzo, that a
warning message is produced by libpq:
message type 0x33 arrived from server while idle
But it is also possible, if queries are sent and results consumed not in
lockstep, for the expected mediating NULL result values from PQgetResult
to be lost (a problem which has not been reported, but which is more
serious).
Fix this by introducing two new concepts: one is a command queue element
PGQUERY_CLOSE to tell libpq to wait for the CloseComplete server
response to the Close message that is sent by PQsendQuery. Because the
application is not expecting any PGresult from this, the mechanism to
consume it is a bit hackish.
The other concept, authored by Horiguchi-san, is a PGASYNC_PIPELINE_IDLE
state for libpq's state machine to differentiate "really idle" from
merely "the idle state that occurs in between reading results from the
server for elements in the pipeline". This makes libpq not go fully
IDLE when the libpq command queue contains entries; in normal cases, we
only go IDLE once at the end of the pipeline, when the server response
to the final SYNC message is received. (However, there are corner cases
it doesn't fix, such as terminating the query sequence by
PQsendFlushRequest instead of PQpipelineSync; this sort of scenario is
what requires PGQUERY_CLOSE bit above.)
This last bit helps make the libpq state machine clearer; in particular
we can get rid of an ugly hack in pqParseInput3 to avoid considering
IDLE as such when the command queue contains entries.
A new test mode is added to libpq_pipeline.c to tickle some related
problematic cases.
Reported-by: Daniele Varrazzo <daniele.varrazzo@gmail.com>
Co-authored-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://postgr.es/m/CA+mi_8bvD0_CW3sumgwPvWdNzXY32itoG_16tDYRu_1S2gV2iw@mail.gmail.com
2022-07-05 14:21:20 +02:00
|
|
|
PGASYNC_COPY_BOTH, /* Copy In/Out data transfer in progress */
|
|
|
|
PGASYNC_PIPELINE_IDLE, /* "Idle" between commands in pipeline mode */
|
1998-09-03 04:10:56 +02:00
|
|
|
} PGAsyncStatusType;
|
|
|
|
|
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 server type (decoded value of target_session_attrs) */
|
|
|
|
typedef enum
|
|
|
|
{
|
|
|
|
SERVER_TYPE_ANY = 0, /* Any server (default) */
|
|
|
|
SERVER_TYPE_READ_WRITE, /* Read-write server */
|
|
|
|
SERVER_TYPE_READ_ONLY, /* Read-only server */
|
|
|
|
SERVER_TYPE_PRIMARY, /* Primary server */
|
|
|
|
SERVER_TYPE_STANDBY, /* Standby server */
|
|
|
|
SERVER_TYPE_PREFER_STANDBY, /* Prefer standby server */
|
|
|
|
SERVER_TYPE_PREFER_STANDBY_PASS2 /* second pass - behaves same as ANY */
|
|
|
|
} PGTargetServerType;
|
|
|
|
|
2023-03-29 21:53:38 +02:00
|
|
|
/* Target server type (decoded value of load_balance_hosts) */
|
|
|
|
typedef enum
|
|
|
|
{
|
|
|
|
LOAD_BALANCE_DISABLE = 0, /* Use the existing host order (default) */
|
|
|
|
LOAD_BALANCE_RANDOM, /* Randomly shuffle the hosts */
|
|
|
|
} PGLoadBalanceType;
|
|
|
|
|
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
|
|
|
/* Boolean value plus a not-known state, for GUCs we might have to fetch */
|
|
|
|
typedef enum
|
|
|
|
{
|
|
|
|
PG_BOOL_UNKNOWN = 0, /* Currently unknown */
|
|
|
|
PG_BOOL_YES, /* Yes (true) */
|
|
|
|
PG_BOOL_NO /* No (false) */
|
|
|
|
} PGTernaryBool;
|
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/* Typedef for the EnvironmentOptions[] array */
|
|
|
|
typedef struct PQEnvironmentOption
|
|
|
|
{
|
|
|
|
const char *envName, /* name of an environment variable */
|
|
|
|
*pgName; /* name of corresponding SET variable */
|
|
|
|
} PQEnvironmentOption;
|
|
|
|
|
|
|
|
/* Typedef for parameter-status list entries */
|
|
|
|
typedef struct pgParameterStatus
|
|
|
|
{
|
|
|
|
struct pgParameterStatus *next; /* list link */
|
|
|
|
char *name; /* parameter name */
|
|
|
|
char *value; /* parameter value */
|
|
|
|
/* Note: name and value are stored in same malloc block as struct is */
|
|
|
|
} pgParameterStatus;
|
|
|
|
|
1998-09-03 04:10:56 +02:00
|
|
|
/* large-object-access data ... allocated only if large-object code is used. */
|
|
|
|
typedef struct pgLobjfuncs
|
|
|
|
{
|
|
|
|
Oid fn_lo_open; /* OID of backend function lo_open */
|
|
|
|
Oid fn_lo_close; /* OID of backend function lo_close */
|
|
|
|
Oid fn_lo_creat; /* OID of backend function lo_creat */
|
2005-06-13 04:26:53 +02:00
|
|
|
Oid fn_lo_create; /* OID of backend function lo_create */
|
1998-09-03 04:10:56 +02:00
|
|
|
Oid fn_lo_unlink; /* OID of backend function lo_unlink */
|
|
|
|
Oid fn_lo_lseek; /* OID of backend function lo_lseek */
|
2012-10-08 03:52:07 +02:00
|
|
|
Oid fn_lo_lseek64; /* OID of backend function lo_lseek64 */
|
1998-09-03 04:10:56 +02:00
|
|
|
Oid fn_lo_tell; /* OID of backend function lo_tell */
|
2012-10-08 03:52:07 +02:00
|
|
|
Oid fn_lo_tell64; /* OID of backend function lo_tell64 */
|
2007-03-03 20:52:47 +01:00
|
|
|
Oid fn_lo_truncate; /* OID of backend function lo_truncate */
|
2012-10-08 03:52:07 +02:00
|
|
|
Oid fn_lo_truncate64; /* OID of function lo_truncate64 */
|
1998-09-03 04:10:56 +02:00
|
|
|
Oid fn_lo_read; /* OID of backend function LOread */
|
|
|
|
Oid fn_lo_write; /* OID of backend function LOwrite */
|
|
|
|
} PGlobjfuncs;
|
|
|
|
|
2012-08-02 19:10:30 +02:00
|
|
|
/* PGdataValue represents a data field value being passed to a row processor.
|
|
|
|
* It could be either text or binary data; text data is not zero-terminated.
|
|
|
|
* A SQL NULL is represented by len < 0; then value is still valid but there
|
|
|
|
* are no data bytes there.
|
|
|
|
*/
|
|
|
|
typedef struct pgDataValue
|
|
|
|
{
|
|
|
|
int len; /* data length in bytes, or <0 if NULL */
|
|
|
|
const char *value; /* data value, without zero-termination */
|
|
|
|
} PGdataValue;
|
|
|
|
|
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
|
|
|
/* Host address type enum for struct pg_conn_host */
|
2016-11-03 14:25:20 +01:00
|
|
|
typedef enum pg_conn_host_type
|
|
|
|
{
|
|
|
|
CHT_HOST_NAME,
|
|
|
|
CHT_HOST_ADDRESS,
|
|
|
|
CHT_UNIX_SOCKET
|
|
|
|
} pg_conn_host_type;
|
|
|
|
|
2021-03-15 22:13:42 +01:00
|
|
|
/*
|
|
|
|
* PGQueryClass tracks which query protocol is in use for each command queue
|
|
|
|
* entry, or special operation in execution
|
|
|
|
*/
|
|
|
|
typedef enum
|
|
|
|
{
|
|
|
|
PGQUERY_SIMPLE, /* simple Query protocol (PQexec) */
|
|
|
|
PGQUERY_EXTENDED, /* full Extended protocol (PQexecParams) */
|
|
|
|
PGQUERY_PREPARE, /* Parse only (PQprepare) */
|
|
|
|
PGQUERY_DESCRIBE, /* Describe Statement or Portal */
|
libpq: Improve idle state handling in pipeline mode
We were going into IDLE state too soon when executing queries via
PQsendQuery in pipeline mode, causing several scenarios to misbehave in
different ways -- most notably, as reported by Daniele Varrazzo, that a
warning message is produced by libpq:
message type 0x33 arrived from server while idle
But it is also possible, if queries are sent and results consumed not in
lockstep, for the expected mediating NULL result values from PQgetResult
to be lost (a problem which has not been reported, but which is more
serious).
Fix this by introducing two new concepts: one is a command queue element
PGQUERY_CLOSE to tell libpq to wait for the CloseComplete server
response to the Close message that is sent by PQsendQuery. Because the
application is not expecting any PGresult from this, the mechanism to
consume it is a bit hackish.
The other concept, authored by Horiguchi-san, is a PGASYNC_PIPELINE_IDLE
state for libpq's state machine to differentiate "really idle" from
merely "the idle state that occurs in between reading results from the
server for elements in the pipeline". This makes libpq not go fully
IDLE when the libpq command queue contains entries; in normal cases, we
only go IDLE once at the end of the pipeline, when the server response
to the final SYNC message is received. (However, there are corner cases
it doesn't fix, such as terminating the query sequence by
PQsendFlushRequest instead of PQpipelineSync; this sort of scenario is
what requires PGQUERY_CLOSE bit above.)
This last bit helps make the libpq state machine clearer; in particular
we can get rid of an ugly hack in pqParseInput3 to avoid considering
IDLE as such when the command queue contains entries.
A new test mode is added to libpq_pipeline.c to tickle some related
problematic cases.
Reported-by: Daniele Varrazzo <daniele.varrazzo@gmail.com>
Co-authored-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://postgr.es/m/CA+mi_8bvD0_CW3sumgwPvWdNzXY32itoG_16tDYRu_1S2gV2iw@mail.gmail.com
2022-07-05 14:21:20 +02:00
|
|
|
PGQUERY_SYNC, /* Sync (at end of a pipeline) */
|
2023-07-04 07:48:10 +02:00
|
|
|
PGQUERY_CLOSE /* Close Statement or Portal */
|
2021-03-15 22:13:42 +01:00
|
|
|
} PGQueryClass;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* An entry in the pending command queue.
|
|
|
|
*/
|
|
|
|
typedef struct PGcmdQueueEntry
|
|
|
|
{
|
|
|
|
PGQueryClass queryclass; /* Query type */
|
|
|
|
char *query; /* SQL command, or NULL if none/unknown/OOM */
|
|
|
|
struct PGcmdQueueEntry *next; /* list link */
|
|
|
|
} PGcmdQueueEntry;
|
|
|
|
|
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
|
|
|
* pg_conn_host stores all information about each of possibly several hosts
|
|
|
|
* mentioned in the connection string. Most fields are derived by splitting
|
|
|
|
* the relevant connection parameter (e.g., pghost) at commas.
|
2016-11-03 14:25:20 +01:00
|
|
|
*/
|
|
|
|
typedef struct pg_conn_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
|
|
|
pg_conn_host_type type; /* type of host address */
|
2017-07-10 11:28:57 +02:00
|
|
|
char *host; /* host name or socket path */
|
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
|
|
|
char *hostaddr; /* host numeric IP address */
|
|
|
|
char *port; /* port number (always provided) */
|
2016-11-03 14:25:20 +01:00
|
|
|
char *password; /* password for this host, read from 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
|
|
|
* password file; NULL if not sought or not
|
|
|
|
* found in password file. */
|
2016-11-03 14:25:20 +01:00
|
|
|
} pg_conn_host;
|
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/*
|
|
|
|
* PGconn stores all the state data associated with a single connection
|
1998-09-03 04:10:56 +02:00
|
|
|
* to a backend.
|
|
|
|
*/
|
|
|
|
struct pg_conn
|
|
|
|
{
|
|
|
|
/* Saved values of connection options */
|
2016-11-03 14:25:20 +01:00
|
|
|
char *pghost; /* the machine on which the server is running,
|
|
|
|
* or a path to a UNIX-domain socket, or a
|
|
|
|
* comma-separated list of machines and/or
|
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
|
|
|
* paths; if NULL, use DEFAULT_PGSOCKET_DIR */
|
2010-07-14 19:09:45 +02:00
|
|
|
char *pghostaddr; /* the numeric IP address of the machine on
|
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
|
|
|
* which the server is running, or a
|
|
|
|
* comma-separated list of same. Takes
|
|
|
|
* precedence over pghost. */
|
|
|
|
char *pgport; /* the server's communication port number, or
|
|
|
|
* a comma-separated list of ports */
|
2003-04-22 02:08:07 +02:00
|
|
|
char *connect_timeout; /* connection timeout (numeric string) */
|
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
|
|
|
char *pgtcp_user_timeout; /* tcp user timeout (numeric string) */
|
2011-02-19 07:54:58 +01:00
|
|
|
char *client_encoding_initial; /* encoding to use */
|
1998-09-03 04:10:56 +02:00
|
|
|
char *pgoptions; /* options to start the backend with */
|
2009-11-29 00:38:08 +01:00
|
|
|
char *appname; /* application name */
|
|
|
|
char *fbappname; /* fallback application name */
|
1998-09-03 04:10:56 +02:00
|
|
|
char *dbName; /* database name */
|
2010-01-15 10:19:10 +01:00
|
|
|
char *replication; /* connect as the replication standby? */
|
1998-09-03 04:10:56 +02:00
|
|
|
char *pguser; /* Postgres username and password, if any */
|
|
|
|
char *pgpass;
|
2017-01-24 23:06:21 +01:00
|
|
|
char *pgpassfile; /* path to a file containing password(s) */
|
2019-09-23 22:45:23 +02:00
|
|
|
char *channel_binding; /* channel binding mode
|
|
|
|
* (require,prefer,disable) */
|
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
|
|
|
char *keepalives; /* use TCP keepalives? */
|
|
|
|
char *keepalives_idle; /* time between TCP keepalives */
|
|
|
|
char *keepalives_interval; /* time between TCP keepalive
|
|
|
|
* retransmits */
|
|
|
|
char *keepalives_count; /* maximum number of TCP keepalive
|
|
|
|
* retransmits */
|
2003-08-01 23:27:27 +02:00
|
|
|
char *sslmode; /* SSL mode (require,prefer,allow,disable) */
|
2021-03-10 01:35:42 +01:00
|
|
|
char *sslcompression; /* SSL compression (0 or 1) */
|
2008-12-15 11:28:22 +01:00
|
|
|
char *sslkey; /* client key filename */
|
|
|
|
char *sslcert; /* client certificate filename */
|
2019-12-20 21:34:07 +01:00
|
|
|
char *sslpassword; /* client key file password */
|
libpq: Add sslcertmode option to control client certificates
The sslcertmode option controls whether the server is allowed and/or
required to request a certificate from the client. There are three
modes:
- "allow" is the default and follows the current behavior, where a
configured client certificate is sent if the server requests one
(via one of its default locations or sslcert). With the current
implementation, will happen whenever TLS is negotiated.
- "disable" causes the client to refuse to send a client certificate
even if sslcert is configured or if a client certificate is available in
one of its default locations.
- "require" causes the client to fail if a client certificate is never
sent and the server opens a connection anyway. This doesn't add any
additional security, since there is no guarantee that the server is
validating the certificate correctly, but it may helpful to troubleshoot
more complicated TLS setups.
sslcertmode=require requires SSL_CTX_set_cert_cb(), available since
OpenSSL 1.0.2. Note that LibreSSL does not include it.
Using a connection parameter different than require_auth has come up as
the simplest design because certificate authentication does not rely
directly on any of the AUTH_REQ_* codes, and one may want to require a
certificate to be sent in combination of a given authentication method,
like SCRAM-SHA-256.
TAP tests are added in src/test/ssl/, some of them relying on sslinfo to
check if a certificate has been set. These are compatible across all
the versions of OpenSSL supported on HEAD (currently down to 1.0.1).
Author: Jacob Champion
Reviewed-by: Aleksander Alekseev, Peter Eisentraut, David G. Johnston,
Michael Paquier
Discussion: https://postgr.es/m/9e5a8ccddb8355ea9fa4b75a1e3a9edc88a70cd3.camel@vmware.com
2023-03-24 05:34:26 +01:00
|
|
|
char *sslcertmode; /* client cert mode (require,allow,disable) */
|
2008-12-15 11:28:22 +01:00
|
|
|
char *sslrootcert; /* root certificate filename */
|
|
|
|
char *sslcrl; /* certificate revocation list filename */
|
2021-02-18 07:59:10 +01:00
|
|
|
char *sslcrldir; /* certificate revocation list directory name */
|
2021-04-07 15:11:41 +02:00
|
|
|
char *sslsni; /* use SSL SNI extension (0 or 1) */
|
2010-07-18 13:37:26 +02:00
|
|
|
char *requirepeer; /* required peer credentials for local sockets */
|
2019-12-20 21:34:07 +01:00
|
|
|
char *gssencmode; /* GSS mode (require,prefer,disable) */
|
2005-06-04 22:42:43 +02:00
|
|
|
char *krbsrvname; /* Kerberos service name */
|
2019-12-20 21:34:07 +01:00
|
|
|
char *gsslib; /* What GSS library to use ("gssapi" or
|
|
|
|
* "sspi") */
|
2023-05-22 17:50:20 +02:00
|
|
|
char *gssdelegation; /* Try to delegate GSS credentials? (0 or 1) */
|
2020-04-30 06:39:10 +02:00
|
|
|
char *ssl_min_protocol_version; /* minimum TLS protocol version */
|
|
|
|
char *ssl_max_protocol_version; /* maximum TLS protocol version */
|
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 *target_session_attrs; /* desired session properties */
|
libpq: Add support for require_auth to control authorized auth methods
The new connection parameter require_auth allows a libpq client to
define a list of comma-separated acceptable authentication types for use
with the server. There is no negotiation: if the server does not
present one of the allowed authentication requests, the connection
attempt done by the client fails.
The following keywords can be defined in the list:
- password, for AUTH_REQ_PASSWORD.
- md5, for AUTH_REQ_MD5.
- gss, for AUTH_REQ_GSS[_CONT].
- sspi, for AUTH_REQ_SSPI and AUTH_REQ_GSS_CONT.
- scram-sha-256, for AUTH_REQ_SASL[_CONT|_FIN].
- creds, for AUTH_REQ_SCM_CREDS (perhaps this should be removed entirely
now).
- none, to control unauthenticated connections.
All the methods that can be defined in the list can be negated, like
"!password", in which case the server must NOT use the listed
authentication type. The special method "none" allows/disallows the use
of unauthenticated connections (but it does not govern transport-level
authentication via TLS or GSSAPI).
Internally, the patch logic is tied to check_expected_areq(), that was
used for channel_binding, ensuring that an incoming request is
compatible with conn->require_auth. It also introduces a new flag,
conn->client_finished_auth, which is set by various authentication
routines when the client side of the handshake is finished. This
signals to check_expected_areq() that an AUTH_REQ_OK from the server is
expected, and allows the client to complain if the server bypasses
authentication entirely, with for example the reception of a too-early
AUTH_REQ_OK message.
Regression tests are added in authentication TAP tests for all the
keywords supported (except "creds", because it is around only for
compatibility reasons). A new TAP script has been added for SSPI, as
there was no script dedicated to it yet. It relies on SSPI being the
default authentication method on Windows, as set by pg_regress.
Author: Jacob Champion
Reviewed-by: Peter Eisentraut, David G. Johnston, Michael Paquier
Discussion: https://postgr.es/m/9e5a8ccddb8355ea9fa4b75a1e3a9edc88a70cd3.camel@vmware.com
2023-03-14 06:00:05 +01:00
|
|
|
char *require_auth; /* name of the expected auth method */
|
2023-03-29 21:53:38 +02:00
|
|
|
char *load_balance_hosts; /* load balance over hosts */
|
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
|
|
|
|
2024-03-12 17:32:25 +01:00
|
|
|
bool cancelRequest; /* true if this connection is used to send a
|
|
|
|
* cancel request, instead of being a normal
|
|
|
|
* connection that's used for queries */
|
|
|
|
|
1998-09-03 04:10:56 +02:00
|
|
|
/* Optional file to write trace info to */
|
|
|
|
FILE *Pfdebug;
|
2021-03-31 01:12:34 +02:00
|
|
|
int traceFlags;
|
1999-05-25 18:15:34 +02:00
|
|
|
|
2003-06-21 23:51:35 +02:00
|
|
|
/* Callback procedures for notice message processing */
|
|
|
|
PGNoticeHooks noticeHooks;
|
1999-05-25 18:15:34 +02:00
|
|
|
|
2008-09-17 06:31:08 +02:00
|
|
|
/* Event procs registered via PQregisterEventProc */
|
|
|
|
PGEvent *events; /* expandable array of event data */
|
|
|
|
int nEvents; /* number of active events */
|
|
|
|
int eventArraySize; /* allocated array size */
|
|
|
|
|
1998-09-03 04:10:56 +02:00
|
|
|
/* Status indicators */
|
|
|
|
ConnStatusType status;
|
|
|
|
PGAsyncStatusType asyncStatus;
|
2006-02-13 23:33:57 +01:00
|
|
|
PGTransactionStatusType xactStatus; /* never changes to ACTIVE */
|
2010-11-27 07:30:34 +01:00
|
|
|
char last_sqlstate[6]; /* last reported SQLSTATE */
|
2006-02-13 23:33:57 +01:00
|
|
|
bool options_valid; /* true if OK to attempt connection */
|
2003-08-13 20:56:21 +02:00
|
|
|
bool nonblocking; /* whether this connection is using nonblock
|
|
|
|
* sending semantics */
|
2021-03-15 22:13:42 +01:00
|
|
|
PGpipelineStatus pipelineStatus; /* status of pipeline mode */
|
Support retrieval of results in chunks with libpq.
This patch generalizes libpq's existing single-row mode to allow
individual partial-result PGresults to contain up to N rows, rather
than always one row. This reduces malloc overhead compared to plain
single-row mode, and it is very useful for psql's FETCH_COUNT feature,
since otherwise we'd have to add code (and cycles) to either merge
single-row PGresults into a bigger one or teach psql's
results-printing logic to accept arrays of PGresults.
To avoid API breakage, PQsetSingleRowMode() remains the same, and we
add a new function PQsetChunkedRowsMode() to invoke the more general
case. Also, PGresults obtained the old way continue to carry the
PGRES_SINGLE_TUPLE status code, while if PQsetChunkedRowsMode() is
used then their status code is PGRES_TUPLES_CHUNK. The underlying
logic is the same either way, though.
Daniel Vérité, reviewed by Laurenz Albe and myself (and whacked
around a bit by me, so any remaining bugs are my fault)
Discussion: https://postgr.es/m/CAKZiRmxsVTkO928CM+-ADvsMyePmU3L9DQCa9NwqjvLPcEe5QA@mail.gmail.com
2024-04-07 02:41:32 +02:00
|
|
|
bool partialResMode; /* true if single-row or chunked mode */
|
2012-08-02 19:10:30 +02:00
|
|
|
bool singleRowMode; /* return current query result row-by-row? */
|
Support retrieval of results in chunks with libpq.
This patch generalizes libpq's existing single-row mode to allow
individual partial-result PGresults to contain up to N rows, rather
than always one row. This reduces malloc overhead compared to plain
single-row mode, and it is very useful for psql's FETCH_COUNT feature,
since otherwise we'd have to add code (and cycles) to either merge
single-row PGresults into a bigger one or teach psql's
results-printing logic to accept arrays of PGresults.
To avoid API breakage, PQsetSingleRowMode() remains the same, and we
add a new function PQsetChunkedRowsMode() to invoke the more general
case. Also, PGresults obtained the old way continue to carry the
PGRES_SINGLE_TUPLE status code, while if PQsetChunkedRowsMode() is
used then their status code is PGRES_TUPLES_CHUNK. The underlying
logic is the same either way, though.
Daniel Vérité, reviewed by Laurenz Albe and myself (and whacked
around a bit by me, so any remaining bugs are my fault)
Discussion: https://postgr.es/m/CAKZiRmxsVTkO928CM+-ADvsMyePmU3L9DQCa9NwqjvLPcEe5QA@mail.gmail.com
2024-04-07 02:41:32 +02:00
|
|
|
int maxChunkSize; /* return query result in chunks not exceeding
|
|
|
|
* this number of rows */
|
2003-06-21 23:51:35 +02:00
|
|
|
char copy_is_binary; /* 1 = copy binary, 0 = copy text */
|
|
|
|
int copy_already_done; /* # bytes already returned in COPY OUT */
|
2004-10-17 00:52:55 +02:00
|
|
|
PGnotify *notifyHead; /* oldest unreported Notify msg */
|
|
|
|
PGnotify *notifyTail; /* newest unreported Notify msg */
|
1999-05-25 18:15:34 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
/* Support for multiple hosts in connection string */
|
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
|
|
|
int nconnhost; /* # of hosts named in conn string */
|
|
|
|
int whichhost; /* host we're currently trying/connected to */
|
|
|
|
pg_conn_host *connhost; /* details about each named host */
|
2018-11-19 18:34:12 +01:00
|
|
|
char *connip; /* IP address for current network connection */
|
2016-11-03 14:25:20 +01:00
|
|
|
|
2021-03-15 22:13:42 +01:00
|
|
|
/*
|
|
|
|
* The pending command queue as a singly-linked list. Head is the command
|
|
|
|
* currently in execution, tail is where new commands are added.
|
|
|
|
*/
|
|
|
|
PGcmdQueueEntry *cmd_queue_head;
|
|
|
|
PGcmdQueueEntry *cmd_queue_tail;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* To save malloc traffic, we don't free entries right away; instead we
|
|
|
|
* save them in this list for possible reuse.
|
|
|
|
*/
|
|
|
|
PGcmdQueueEntry *cmd_queue_recycle;
|
|
|
|
|
1998-09-03 04:10:56 +02:00
|
|
|
/* Connection data */
|
2014-04-17 01:46:51 +02:00
|
|
|
pgsocket sock; /* FD for socket, PGINVALID_SOCKET if
|
|
|
|
* unconnected */
|
1998-09-03 04:10:56 +02:00
|
|
|
SockAddr laddr; /* Local address */
|
|
|
|
SockAddr raddr; /* Remote address */
|
2003-06-08 19:43:00 +02:00
|
|
|
ProtocolVersion pversion; /* FE/BE protocol version in use */
|
2004-03-05 02:53:59 +01:00
|
|
|
int sversion; /* server version, e.g. 70401 for 7.4.1 */
|
2010-11-27 08:11:45 +01:00
|
|
|
bool auth_req_received; /* true if any type of auth req received */
|
2007-12-09 20:01:40 +01:00
|
|
|
bool password_needed; /* true if server demanded a password */
|
2023-04-13 14:55:07 +02:00
|
|
|
bool gssapi_used; /* true if authenticated via gssapi */
|
2009-07-24 19:58:31 +02:00
|
|
|
bool sigpipe_so; /* have we masked SIGPIPE via SO_NOSIGPIPE? */
|
|
|
|
bool sigpipe_flag; /* can we mask SIGPIPE via MSG_NOSIGNAL? */
|
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
|
|
|
bool write_failed; /* have we had a write failure on sock? */
|
|
|
|
char *write_err_msg; /* write error message, or NULL if OOM */
|
2003-06-08 19:43:00 +02:00
|
|
|
|
libpq: Add support for require_auth to control authorized auth methods
The new connection parameter require_auth allows a libpq client to
define a list of comma-separated acceptable authentication types for use
with the server. There is no negotiation: if the server does not
present one of the allowed authentication requests, the connection
attempt done by the client fails.
The following keywords can be defined in the list:
- password, for AUTH_REQ_PASSWORD.
- md5, for AUTH_REQ_MD5.
- gss, for AUTH_REQ_GSS[_CONT].
- sspi, for AUTH_REQ_SSPI and AUTH_REQ_GSS_CONT.
- scram-sha-256, for AUTH_REQ_SASL[_CONT|_FIN].
- creds, for AUTH_REQ_SCM_CREDS (perhaps this should be removed entirely
now).
- none, to control unauthenticated connections.
All the methods that can be defined in the list can be negated, like
"!password", in which case the server must NOT use the listed
authentication type. The special method "none" allows/disallows the use
of unauthenticated connections (but it does not govern transport-level
authentication via TLS or GSSAPI).
Internally, the patch logic is tied to check_expected_areq(), that was
used for channel_binding, ensuring that an incoming request is
compatible with conn->require_auth. It also introduces a new flag,
conn->client_finished_auth, which is set by various authentication
routines when the client side of the handshake is finished. This
signals to check_expected_areq() that an AUTH_REQ_OK from the server is
expected, and allows the client to complain if the server bypasses
authentication entirely, with for example the reception of a too-early
AUTH_REQ_OK message.
Regression tests are added in authentication TAP tests for all the
keywords supported (except "creds", because it is around only for
compatibility reasons). A new TAP script has been added for SSPI, as
there was no script dedicated to it yet. It relies on SSPI being the
default authentication method on Windows, as set by pg_regress.
Author: Jacob Champion
Reviewed-by: Peter Eisentraut, David G. Johnston, Michael Paquier
Discussion: https://postgr.es/m/9e5a8ccddb8355ea9fa4b75a1e3a9edc88a70cd3.camel@vmware.com
2023-03-14 06:00:05 +01:00
|
|
|
bool auth_required; /* require an authentication challenge from
|
|
|
|
* the server? */
|
|
|
|
uint32 allowed_auth_methods; /* bitmask of acceptable AuthRequest
|
|
|
|
* codes */
|
|
|
|
bool client_finished_auth; /* have we finished our half of the
|
|
|
|
* authentication exchange? */
|
|
|
|
|
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/* Transient state needed while establishing connection */
|
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
|
|
|
PGTargetServerType target_server_type; /* desired session properties */
|
2023-03-29 21:53:38 +02:00
|
|
|
PGLoadBalanceType load_balance_type; /* desired load balancing
|
|
|
|
* algorithm */
|
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 try_next_addr; /* time to advance to next address/host? */
|
|
|
|
bool try_next_host; /* time to advance to next connhost[]? */
|
2023-03-29 21:41:27 +02:00
|
|
|
int naddr; /* number of addresses returned by getaddrinfo */
|
|
|
|
int whichaddr; /* the address currently being tried */
|
|
|
|
AddrInfo *addr; /* the array of addresses for the currently
|
|
|
|
* tried host */
|
2009-12-02 05:38:35 +01:00
|
|
|
bool send_appname; /* okay to send application_name? */
|
1999-05-25 18:15:34 +02:00
|
|
|
|
1998-09-03 04:10:56 +02:00
|
|
|
/* Miscellaneous stuff */
|
|
|
|
int be_pid; /* PID of backend --- needed for cancels */
|
|
|
|
int be_key; /* key of backend --- needed for cancels */
|
2003-06-08 19:43:00 +02:00
|
|
|
pgParameterStatus *pstatus; /* ParameterStatus data */
|
2003-04-22 02:08:07 +02:00
|
|
|
int client_encoding; /* encoding id */
|
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
|
|
|
bool std_strings; /* standard_conforming_strings */
|
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
|
|
|
PGTernaryBool default_transaction_read_only; /* default_transaction_read_only */
|
|
|
|
PGTernaryBool in_hot_standby; /* in_hot_standby */
|
2003-06-21 23:51:35 +02:00
|
|
|
PGVerbosity verbosity; /* error/notice message verbosity */
|
2015-09-05 17:58:20 +02:00
|
|
|
PGContextVisibility show_context; /* whether to show CONTEXT field */
|
1998-09-03 04:10:56 +02:00
|
|
|
PGlobjfuncs *lobjfuncs; /* private state for large-object access fns */
|
2023-03-29 21:53:38 +02:00
|
|
|
pg_prng_state prng_state; /* prng state for load balancing connections */
|
|
|
|
|
1999-05-25 18:15:34 +02:00
|
|
|
|
1998-09-03 04:10:56 +02:00
|
|
|
/* Buffer for data received from backend and not yet processed */
|
|
|
|
char *inBuffer; /* currently allocated buffer */
|
|
|
|
int inBufSize; /* allocated size of buffer */
|
|
|
|
int inStart; /* offset to first unconsumed data in buffer */
|
|
|
|
int inCursor; /* next byte to tentatively consume */
|
|
|
|
int inEnd; /* offset to first position after avail data */
|
1999-05-25 18:15:34 +02:00
|
|
|
|
1998-09-03 04:10:56 +02:00
|
|
|
/* Buffer for data not yet sent to backend */
|
|
|
|
char *outBuffer; /* currently allocated buffer */
|
|
|
|
int outBufSize; /* allocated size of buffer */
|
|
|
|
int outCount; /* number of chars waiting in buffer */
|
1999-05-25 18:15:34 +02:00
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
/* State for constructing messages in outBuffer */
|
2003-06-08 19:43:00 +02:00
|
|
|
int outMsgStart; /* offset to msg start (length word); if -1,
|
|
|
|
* msg has no length word */
|
2003-04-19 02:02:30 +02:00
|
|
|
int outMsgEnd; /* offset to msg end (so far) */
|
|
|
|
|
2012-04-05 00:27:56 +02:00
|
|
|
/* Row processor interface workspace */
|
|
|
|
PGdataValue *rowBuf; /* array for passing values to rowProcessor */
|
|
|
|
int rowBufLen; /* number of entries allocated in rowBuf */
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Status for asynchronous result construction. If result isn't NULL, it
|
|
|
|
* is a result being constructed or ready to return. If result is NULL
|
|
|
|
* and error_result is true, then we need to return a PGRES_FATAL_ERROR
|
|
|
|
* result, but haven't yet constructed it; text for the error has been
|
|
|
|
* appended to conn->errorMessage. (Delaying construction simplifies
|
Support retrieval of results in chunks with libpq.
This patch generalizes libpq's existing single-row mode to allow
individual partial-result PGresults to contain up to N rows, rather
than always one row. This reduces malloc overhead compared to plain
single-row mode, and it is very useful for psql's FETCH_COUNT feature,
since otherwise we'd have to add code (and cycles) to either merge
single-row PGresults into a bigger one or teach psql's
results-printing logic to accept arrays of PGresults.
To avoid API breakage, PQsetSingleRowMode() remains the same, and we
add a new function PQsetChunkedRowsMode() to invoke the more general
case. Also, PGresults obtained the old way continue to carry the
PGRES_SINGLE_TUPLE status code, while if PQsetChunkedRowsMode() is
used then their status code is PGRES_TUPLES_CHUNK. The underlying
logic is the same either way, though.
Daniel Vérité, reviewed by Laurenz Albe and myself (and whacked
around a bit by me, so any remaining bugs are my fault)
Discussion: https://postgr.es/m/CAKZiRmxsVTkO928CM+-ADvsMyePmU3L9DQCa9NwqjvLPcEe5QA@mail.gmail.com
2024-04-07 02:41:32 +02:00
|
|
|
* dealing with out-of-memory cases.) If saved_result isn't NULL, it is a
|
|
|
|
* PGresult that will replace "result" after we return that one; we use
|
|
|
|
* that in partial-result mode to remember the query's tuple metadata.
|
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
|
|
|
*/
|
1998-09-03 04:10:56 +02:00
|
|
|
PGresult *result; /* result being constructed */
|
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
|
|
|
bool error_result; /* do we need to make an ERROR result? */
|
Support retrieval of results in chunks with libpq.
This patch generalizes libpq's existing single-row mode to allow
individual partial-result PGresults to contain up to N rows, rather
than always one row. This reduces malloc overhead compared to plain
single-row mode, and it is very useful for psql's FETCH_COUNT feature,
since otherwise we'd have to add code (and cycles) to either merge
single-row PGresults into a bigger one or teach psql's
results-printing logic to accept arrays of PGresults.
To avoid API breakage, PQsetSingleRowMode() remains the same, and we
add a new function PQsetChunkedRowsMode() to invoke the more general
case. Also, PGresults obtained the old way continue to carry the
PGRES_SINGLE_TUPLE status code, while if PQsetChunkedRowsMode() is
used then their status code is PGRES_TUPLES_CHUNK. The underlying
logic is the same either way, though.
Daniel Vérité, reviewed by Laurenz Albe and myself (and whacked
around a bit by me, so any remaining bugs are my fault)
Discussion: https://postgr.es/m/CAKZiRmxsVTkO928CM+-ADvsMyePmU3L9DQCa9NwqjvLPcEe5QA@mail.gmail.com
2024-04-07 02:41:32 +02:00
|
|
|
PGresult *saved_result; /* original, empty result in partialResMode */
|
2012-04-05 00:27:56 +02:00
|
|
|
|
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
|
|
|
/* Assorted state for SASL, SSL, GSS, etc */
|
2021-07-07 03:55:15 +02:00
|
|
|
const pg_fe_sasl_mech *sasl;
|
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
|
|
|
void *sasl_state;
|
2023-03-27 09:46:29 +02:00
|
|
|
int scram_sha_256_iterations;
|
1999-05-25 18:15:34 +02:00
|
|
|
|
2017-11-18 16:07:57 +01:00
|
|
|
/* SSL structures */
|
|
|
|
bool ssl_in_use;
|
libpq: Add sslcertmode option to control client certificates
The sslcertmode option controls whether the server is allowed and/or
required to request a certificate from the client. There are three
modes:
- "allow" is the default and follows the current behavior, where a
configured client certificate is sent if the server requests one
(via one of its default locations or sslcert). With the current
implementation, will happen whenever TLS is negotiated.
- "disable" causes the client to refuse to send a client certificate
even if sslcert is configured or if a client certificate is available in
one of its default locations.
- "require" causes the client to fail if a client certificate is never
sent and the server opens a connection anyway. This doesn't add any
additional security, since there is no guarantee that the server is
validating the certificate correctly, but it may helpful to troubleshoot
more complicated TLS setups.
sslcertmode=require requires SSL_CTX_set_cert_cb(), available since
OpenSSL 1.0.2. Note that LibreSSL does not include it.
Using a connection parameter different than require_auth has come up as
the simplest design because certificate authentication does not rely
directly on any of the AUTH_REQ_* codes, and one may want to require a
certificate to be sent in combination of a given authentication method,
like SCRAM-SHA-256.
TAP tests are added in src/test/ssl/, some of them relying on sslinfo to
check if a certificate has been set. These are compatible across all
the versions of OpenSSL supported on HEAD (currently down to 1.0.1).
Author: Jacob Champion
Reviewed-by: Aleksander Alekseev, Peter Eisentraut, David G. Johnston,
Michael Paquier
Discussion: https://postgr.es/m/9e5a8ccddb8355ea9fa4b75a1e3a9edc88a70cd3.camel@vmware.com
2023-03-24 05:34:26 +01:00
|
|
|
bool ssl_cert_requested; /* Did the server ask us for a cert? */
|
|
|
|
bool ssl_cert_sent; /* Did we send one in reply? */
|
2017-11-18 16:07:57 +01:00
|
|
|
|
1999-09-27 05:13:16 +02:00
|
|
|
#ifdef USE_SSL
|
2000-01-14 06:33:15 +01:00
|
|
|
bool allow_ssl_try; /* Allowed to try SSL negotiation */
|
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
|
|
|
bool wait_ssl_try; /* Delay SSL negotiation until after
|
2003-08-01 23:27:27 +02:00
|
|
|
* attempting normal connection */
|
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
|
|
|
#ifdef USE_OPENSSL
|
2000-01-14 06:33:15 +01:00
|
|
|
SSL *ssl; /* SSL status, if have SSL connection */
|
UPDATED PATCH:
Attached are a revised set of SSL patches. Many of these patches
are motivated by security concerns, it's not just bug fixes. The key
differences (from stock 7.2.1) are:
*) almost all code that directly uses the OpenSSL library is in two
new files,
src/interfaces/libpq/fe-ssl.c
src/backend/postmaster/be-ssl.c
in the long run, it would be nice to merge these two files.
*) the legacy code to read and write network data have been
encapsulated into read_SSL() and write_SSL(). These functions
should probably be renamed - they handle both SSL and non-SSL
cases.
the remaining code should eliminate the problems identified
earlier, albeit not very cleanly.
*) both front- and back-ends will send a SSL shutdown via the
new close_SSL() function. This is necessary for sessions to
work properly.
(Sessions are not yet fully supported, but by cleanly closing
the SSL connection instead of just sending a TCP FIN packet
other SSL tools will be much happier.)
*) The client certificate and key are now expected in a subdirectory
of the user's home directory. Specifically,
- the directory .postgresql must be owned by the user, and
allow no access by 'group' or 'other.'
- the file .postgresql/postgresql.crt must be a regular file
owned by the user.
- the file .postgresql/postgresql.key must be a regular file
owned by the user, and allow no access by 'group' or 'other'.
At the current time encrypted private keys are not supported.
There should also be a way to support multiple client certs/keys.
*) the front-end performs minimal validation of the back-end cert.
Self-signed certs are permitted, but the common name *must*
match the hostname used by the front-end. (The cert itself
should always use a fully qualified domain name (FDQN) in its
common name field.)
This means that
psql -h eris db
will fail, but
psql -h eris.example.com db
will succeed. At the current time this must be an exact match;
future patches may support any FQDN that resolves to the address
returned by getpeername(2).
Another common "problem" is expiring certs. For now, it may be
a good idea to use a very-long-lived self-signed cert.
As a compile-time option, the front-end can specify a file
containing valid root certificates, but it is not yet required.
*) the back-end performs minimal validation of the client cert.
It allows self-signed certs. It checks for expiration. It
supports a compile-time option specifying a file containing
valid root certificates.
*) both front- and back-ends default to TLSv1, not SSLv3/SSLv2.
*) both front- and back-ends support DSA keys. DSA keys are
moderately more expensive on startup, but many people consider
them preferable than RSA keys. (E.g., SSH2 prefers DSA keys.)
*) if /dev/urandom exists, both client and server will read 16k
of randomization data from it.
*) the server can read empheral DH parameters from the files
$DataDir/dh512.pem
$DataDir/dh1024.pem
$DataDir/dh2048.pem
$DataDir/dh4096.pem
if none are provided, the server will default to hardcoded
parameter files provided by the OpenSSL project.
Remaining tasks:
*) the select() clauses need to be revisited - the SSL abstraction
layer may need to absorb more of the current code to avoid rare
deadlock conditions. This also touches on a true solution to
the pg_eof() problem.
*) the SIGPIPE signal handler may need to be revisited.
*) support encrypted private keys.
*) sessions are not yet fully supported. (SSL sessions can span
multiple "connections," and allow the client and server to avoid
costly renegotiations.)
*) makecert - a script that creates back-end certs.
*) pgkeygen - a tool that creates front-end certs.
*) the whole protocol issue, SASL, etc.
*) certs are fully validated - valid root certs must be available.
This is a hassle, but it means that you *can* trust the identity
of the server.
*) the client library can handle hardcoded root certificates, to
avoid the need to copy these files.
*) host name of server cert must resolve to IP address, or be a
recognized alias. This is more liberal than the previous
iteration.
*) the number of bytes transferred is tracked, and the session
key is periodically renegotiated.
*) basic cert generation scripts (mkcert.sh, pgkeygen.sh). The
configuration files have reasonable defaults for each type
of use.
Bear Giles
2002-06-14 06:23:17 +02:00
|
|
|
X509 *peer; /* X509 cert of server */
|
2009-06-23 20:13:23 +02:00
|
|
|
#ifdef USE_SSL_ENGINE
|
|
|
|
ENGINE *engine; /* SSL engine, if any */
|
|
|
|
#else
|
|
|
|
void *engine; /* dummy field to keep struct the same if
|
|
|
|
* OpenSSL version changes */
|
1999-09-27 05:13:16 +02:00
|
|
|
#endif
|
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
|
|
|
bool crypto_loaded; /* Track if libcrypto locking callbacks have
|
|
|
|
* been done for this connection. This can be
|
|
|
|
* removed once support for OpenSSL 1.0.2 is
|
|
|
|
* removed as this locking is handled
|
|
|
|
* internally in OpenSSL >= 1.1.0. */
|
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
|
|
|
#endif /* USE_OPENSSL */
|
2009-06-23 20:13:23 +02:00
|
|
|
#endif /* USE_SSL */
|
1999-09-27 05:13:16 +02:00
|
|
|
|
2007-07-10 15:14:22 +02:00
|
|
|
#ifdef ENABLE_GSS
|
|
|
|
gss_ctx_id_t gctx; /* GSS context */
|
|
|
|
gss_name_t gtarg_nam; /* GSS target name */
|
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
|
|
|
|
|
|
|
/* The following are encryption-only */
|
|
|
|
bool try_gss; /* GSS attempting permitted */
|
|
|
|
bool gssenc; /* GSS encryption is usable */
|
|
|
|
gss_cred_id_t gcred; /* GSS credential temp storage. */
|
2020-01-11 23:14:08 +01:00
|
|
|
|
|
|
|
/* GSS encryption I/O state --- see fe-secure-gssapi.c */
|
|
|
|
char *gss_SendBuffer; /* Encrypted data waiting to be sent */
|
|
|
|
int gss_SendLength; /* End of data available in gss_SendBuffer */
|
|
|
|
int gss_SendNext; /* Next index to send a byte from
|
|
|
|
* gss_SendBuffer */
|
Fix timing-dependent failure in GSSAPI data transmission.
When using GSSAPI encryption in non-blocking mode, libpq sometimes
failed with "GSSAPI caller failed to retransmit all data needing
to be retried". The cause is that pqPutMsgEnd rounds its transmit
request down to an even multiple of 8K, and sometimes that can lead
to not requesting a write of data that was requested to be written
(but reported as not written) earlier. That can upset pg_GSS_write's
logic for dealing with not-yet-written data, since it's possible
the data in question had already been incorporated into an encrypted
packet that we weren't able to send during the previous call.
We could fix this with a one-or-two-line hack to disable pqPutMsgEnd's
round-down behavior, but that seems like making the caller work around
a behavior that pg_GSS_write shouldn't expose in this way. Instead,
adjust pg_GSS_write to never report a partial write: it either
reports a complete write, or reflects the failure of the lower-level
pqsecure_raw_write call. The requirement still exists for the caller
to present at least as much data as on the previous call, but with
the caller-visible write start point not moving there is no temptation
for it to present less. We lose some ability to reclaim buffer space
early, but I doubt that that will make much difference in practice.
This also gets rid of a rather dubious assumption that "any
interesting failure condition (from pqsecure_raw_write) will recur
on the next try". We've not seen failure reports traceable to that,
but I've never trusted it particularly and am glad to remove it.
Make the same adjustments to the equivalent backend routine
be_gssapi_write(). It is probable that there's no bug on the backend
side, since we don't have a notion of nonblock mode there; but we
should keep the logic the same to ease future maintenance.
Per bug #18210 from Lars Kanis. Back-patch to all supported branches.
Discussion: https://postgr.es/m/18210-4c6d0b14627f2eb8@postgresql.org
2023-11-23 19:30:18 +01:00
|
|
|
int gss_SendConsumed; /* Number of source bytes encrypted but
|
|
|
|
* not yet reported as sent */
|
2020-01-11 23:14:08 +01:00
|
|
|
char *gss_RecvBuffer; /* Received, encrypted data */
|
|
|
|
int gss_RecvLength; /* End of data available in gss_RecvBuffer */
|
|
|
|
char *gss_ResultBuffer; /* Decryption of data in gss_RecvBuffer */
|
|
|
|
int gss_ResultLength; /* End of data available in
|
|
|
|
* gss_ResultBuffer */
|
|
|
|
int gss_ResultNext; /* Next index to read a byte from
|
|
|
|
* gss_ResultBuffer */
|
|
|
|
uint32 gss_MaxPktSize; /* Maximum size we can encrypt and fit the
|
|
|
|
* results into our output buffer */
|
2007-07-10 15:14:22 +02:00
|
|
|
#endif
|
|
|
|
|
2007-07-23 12:16:54 +02:00
|
|
|
#ifdef ENABLE_SSPI
|
|
|
|
CredHandle *sspicred; /* SSPI credentials handle */
|
|
|
|
CtxtHandle *sspictx; /* SSPI context */
|
|
|
|
char *sspitarget; /* SSPI target name */
|
|
|
|
int usesspi; /* Indicate if SSPI is in use on the
|
|
|
|
* connection */
|
|
|
|
#endif
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Buffer for current error message. This is cleared at the start of any
|
|
|
|
* connection attempt or query cycle; after that, all code should append
|
|
|
|
* messages to it, never overwrite.
|
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
|
|
|
*
|
|
|
|
* In some situations we might report an error more than once in a query
|
|
|
|
* cycle. If so, errorMessage accumulates text from all the errors, and
|
|
|
|
* errorReported tracks how much we've already reported, so that the
|
|
|
|
* individual error PGresult objects don't contain duplicative text.
|
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
|
|
|
*/
|
1999-08-31 03:37:37 +02:00
|
|
|
PQExpBufferData errorMessage; /* expansible string */
|
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
|
|
|
int errorReported; /* # bytes of string already reported */
|
1999-08-31 03:37:37 +02:00
|
|
|
|
|
|
|
/* Buffer for receiving various parts of messages */
|
|
|
|
PQExpBufferData workBuffer; /* expansible string */
|
1998-09-03 04:10:56 +02:00
|
|
|
};
|
|
|
|
|
2004-10-31 01:11:27 +02:00
|
|
|
|
2000-02-08 00:10:11 +01:00
|
|
|
/* String descriptions of the ExecStatusTypes.
|
|
|
|
* direct use of this array is deprecated; call PQresStatus() instead.
|
|
|
|
*/
|
|
|
|
extern char *const pgresStatus[];
|
|
|
|
|
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
|
|
|
|
|
|
|
#ifdef USE_SSL
|
|
|
|
|
|
|
|
#ifndef WIN32
|
|
|
|
#define USER_CERT_FILE ".postgresql/postgresql.crt"
|
|
|
|
#define USER_KEY_FILE ".postgresql/postgresql.key"
|
|
|
|
#define ROOT_CERT_FILE ".postgresql/root.crt"
|
|
|
|
#define ROOT_CRL_FILE ".postgresql/root.crl"
|
|
|
|
#else
|
|
|
|
/* On Windows, the "home" directory is already PostgreSQL-specific */
|
|
|
|
#define USER_CERT_FILE "postgresql.crt"
|
|
|
|
#define USER_KEY_FILE "postgresql.key"
|
|
|
|
#define ROOT_CERT_FILE "root.crt"
|
|
|
|
#define ROOT_CRL_FILE "root.crl"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#endif /* USE_SSL */
|
|
|
|
|
1998-08-17 05:52:36 +02:00
|
|
|
/* ----------------
|
|
|
|
* Internal functions of libpq
|
|
|
|
* Functions declared here need to be visible across files of libpq,
|
|
|
|
* but are not intended to be called by applications. We use the
|
|
|
|
* convention "pqXXX" for internal functions, vs. the "PQxxx" names
|
|
|
|
* used for application-visible routines.
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* === in fe-connect.c === */
|
|
|
|
|
2015-11-12 19:03:52 +01:00
|
|
|
extern void pqDropConnection(PGconn *conn, bool flushInput);
|
2024-02-04 16:35:16 +01:00
|
|
|
extern bool pqConnectOptions2(PGconn *conn);
|
2024-01-29 10:53:34 +01:00
|
|
|
#if defined(WIN32) && defined(SIO_KEEPALIVE_VALS)
|
|
|
|
extern int pqSetKeepalivesWin32(pgsocket sock, int idle, int interval);
|
|
|
|
#endif
|
2024-02-04 16:35:16 +01:00
|
|
|
extern int pqConnectDBStart(PGconn *conn);
|
|
|
|
extern int pqConnectDBComplete(PGconn *conn);
|
|
|
|
extern PGconn *pqMakeEmptyPGconn(void);
|
2024-02-04 16:19:20 +01:00
|
|
|
extern void pqReleaseConnHosts(PGconn *conn);
|
2024-02-04 16:35:16 +01:00
|
|
|
extern void pqClosePGconn(PGconn *conn);
|
2003-04-18 00:26:02 +02:00
|
|
|
extern int pqPacketSend(PGconn *conn, char pack_type,
|
|
|
|
const void *buf, size_t buf_len);
|
2005-01-06 02:00:12 +01:00
|
|
|
extern bool pqGetHomeDirectory(char *buf, int bufsize);
|
2024-03-12 17:32:25 +01:00
|
|
|
extern bool pqCopyPGconn(PGconn *srcConn, PGconn *dstConn);
|
2024-01-29 10:53:34 +01:00
|
|
|
extern bool pqParseIntParam(const char *value, int *result, PGconn *conn,
|
|
|
|
const char *context);
|
1998-08-17 05:52:36 +02:00
|
|
|
|
2004-12-03 00:20:21 +01:00
|
|
|
extern pgthreadlock_t pg_g_threadlock;
|
2004-08-29 07:07:03 +02:00
|
|
|
|
2004-12-03 00:20:21 +01:00
|
|
|
#define pglock_thread() pg_g_threadlock(true)
|
|
|
|
#define pgunlock_thread() pg_g_threadlock(false)
|
2004-08-29 07:07:03 +02:00
|
|
|
|
1998-08-17 05:52:36 +02:00
|
|
|
/* === in fe-exec.c === */
|
|
|
|
|
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
|
|
|
extern void pqSetResultError(PGresult *res, PQExpBuffer errorMessage, int offset);
|
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
|
|
|
extern void *pqResultAlloc(PGresult *res, size_t nBytes, bool isBinary);
|
1998-11-18 01:47:28 +01:00
|
|
|
extern char *pqResultStrdup(PGresult *res, const char *str);
|
1998-08-17 05:52:36 +02:00
|
|
|
extern void pqClearAsyncResult(PGconn *conn);
|
2003-06-08 19:43:00 +02:00
|
|
|
extern void pqSaveErrorResult(PGconn *conn);
|
|
|
|
extern PGresult *pqPrepareAsyncResult(PGconn *conn);
|
2005-06-12 02:00:21 +02:00
|
|
|
extern void pqInternalNotice(const PGNoticeHooks *hooks, const char *fmt,...) pg_attribute_printf(2, 3);
|
2003-06-21 23:51:35 +02:00
|
|
|
extern void pqSaveMessageField(PGresult *res, char code,
|
|
|
|
const char *value);
|
2003-06-08 19:43:00 +02:00
|
|
|
extern void pqSaveParameterStatus(PGconn *conn, const char *name,
|
|
|
|
const char *value);
|
2012-08-02 19:10:30 +02:00
|
|
|
extern int pqRowProcessor(PGconn *conn, const char **errmsgp);
|
2023-12-05 12:43:24 +01:00
|
|
|
extern void pqCommandQueueAdvance(PGconn *conn, bool isReadyForQuery,
|
|
|
|
bool gotSync);
|
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
|
|
|
extern int PQsendQueryContinue(PGconn *conn, const char *query);
|
2003-06-08 19:43:00 +02:00
|
|
|
|
|
|
|
/* === in fe-protocol3.c === */
|
|
|
|
|
|
|
|
extern char *pqBuildStartupPacket3(PGconn *conn, int *packetlen,
|
|
|
|
const PQEnvironmentOption *options);
|
|
|
|
extern void pqParseInput3(PGconn *conn);
|
|
|
|
extern int pqGetErrorNotice3(PGconn *conn, bool isError);
|
2016-04-03 18:24:54 +02:00
|
|
|
extern void pqBuildErrorMessage3(PQExpBuffer msg, const PGresult *res,
|
|
|
|
PGVerbosity verbosity, PGContextVisibility show_context);
|
2022-11-17 15:14:44 +01:00
|
|
|
extern int pqGetNegotiateProtocolVersion3(PGconn *conn);
|
2003-06-21 23:51:35 +02:00
|
|
|
extern int pqGetCopyData3(PGconn *conn, char **buffer, int async);
|
2003-06-08 19:43:00 +02:00
|
|
|
extern int pqGetline3(PGconn *conn, char *s, int maxlen);
|
|
|
|
extern int pqGetlineAsync3(PGconn *conn, char *buffer, int bufsize);
|
|
|
|
extern int pqEndcopy3(PGconn *conn);
|
|
|
|
extern PGresult *pqFunctionCall3(PGconn *conn, Oid fnid,
|
|
|
|
int *result_buf, int *actual_result_len,
|
|
|
|
int result_is_int,
|
|
|
|
const PQArgBlock *args, int nargs);
|
1998-08-17 05:52:36 +02:00
|
|
|
|
|
|
|
/* === in fe-misc.c === */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* "Get" and "Put" routines return 0 if successful, EOF if not. Note that for
|
|
|
|
* Get, EOF merely means the buffer is exhausted, not that there is
|
|
|
|
* necessarily any error.
|
|
|
|
*/
|
2008-05-30 00:02:44 +02:00
|
|
|
extern int pqCheckOutBufferSpace(size_t bytes_needed, PGconn *conn);
|
|
|
|
extern int pqCheckInBufferSpace(size_t bytes_needed, PGconn *conn);
|
1998-08-17 05:52:36 +02:00
|
|
|
extern int pqGetc(char *result, PGconn *conn);
|
2001-07-06 19:58:53 +02:00
|
|
|
extern int pqPutc(char c, PGconn *conn);
|
1999-08-31 03:37:37 +02:00
|
|
|
extern int pqGets(PQExpBuffer buf, PGconn *conn);
|
2008-10-27 10:42:31 +01:00
|
|
|
extern int pqGets_append(PQExpBuffer buf, PGconn *conn);
|
1998-08-17 05:52:36 +02:00
|
|
|
extern int pqPuts(const char *s, PGconn *conn);
|
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
|
|
|
extern int pqGetnchar(char *s, size_t len, PGconn *conn);
|
2012-04-05 00:27:56 +02:00
|
|
|
extern int pqSkipnchar(size_t len, PGconn *conn);
|
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
|
|
|
extern int pqPutnchar(const char *s, size_t len, PGconn *conn);
|
|
|
|
extern int pqGetInt(int *result, size_t bytes, PGconn *conn);
|
|
|
|
extern int pqPutInt(int value, size_t bytes, PGconn *conn);
|
2021-03-04 09:45:55 +01:00
|
|
|
extern int pqPutMsgStart(char msg_type, PGconn *conn);
|
2003-04-19 02:02:30 +02:00
|
|
|
extern int pqPutMsgEnd(PGconn *conn);
|
1998-08-17 05:52:36 +02:00
|
|
|
extern int pqReadData(PGconn *conn);
|
|
|
|
extern int pqFlush(PGconn *conn);
|
|
|
|
extern int pqWait(int forRead, int forWrite, PGconn *conn);
|
2002-10-16 04:55:30 +02:00
|
|
|
extern int pqWaitTimed(int forRead, int forWrite, PGconn *conn,
|
|
|
|
time_t finish_time);
|
1999-11-30 04:08:19 +01:00
|
|
|
extern int pqReadReady(PGconn *conn);
|
|
|
|
extern int pqWriteReady(PGconn *conn);
|
1998-08-17 05:52:36 +02:00
|
|
|
|
2002-06-16 00:06:09 +02:00
|
|
|
/* === in fe-secure.c === */
|
|
|
|
|
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
|
|
|
extern int pqsecure_initialize(PGconn *, bool, bool);
|
2003-06-08 19:43:00 +02:00
|
|
|
extern PostgresPollingStatusType pqsecure_open_client(PGconn *);
|
2002-06-16 00:06:09 +02:00
|
|
|
extern void pqsecure_close(PGconn *);
|
|
|
|
extern ssize_t pqsecure_read(PGconn *, void *ptr, size_t len);
|
|
|
|
extern ssize_t pqsecure_write(PGconn *, const void *ptr, size_t len);
|
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
|
|
|
extern ssize_t pqsecure_raw_read(PGconn *, void *ptr, size_t len);
|
|
|
|
extern ssize_t pqsecure_raw_write(PGconn *, const void *ptr, size_t len);
|
2004-08-29 07:07:03 +02:00
|
|
|
|
2023-07-11 20:20:37 +02:00
|
|
|
#if !defined(WIN32)
|
2004-12-03 00:20:21 +01:00
|
|
|
extern int pq_block_sigpipe(sigset_t *osigset, bool *sigpipe_pending);
|
|
|
|
extern void pq_reset_sigpipe(sigset_t *osigset, bool sigpipe_pending,
|
|
|
|
bool got_epipe);
|
2004-12-02 16:32:54 +01:00
|
|
|
#endif
|
|
|
|
|
2018-01-19 01:53:22 +01:00
|
|
|
/* === SSL === */
|
|
|
|
|
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
|
|
|
/*
|
2018-01-19 01:53:22 +01:00
|
|
|
* The SSL implementation provides these functions.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Implementation of PQinitSSL().
|
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
|
|
|
*/
|
|
|
|
extern void pgtls_init_library(bool do_ssl, int do_crypto);
|
2018-01-19 01:53:22 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize SSL library.
|
|
|
|
*
|
|
|
|
* The conn parameter is only used to be able to pass back an error
|
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
|
|
|
* message - no connection-local setup is made here. do_ssl controls
|
|
|
|
* if SSL is initialized, and do_crypto does the same for the crypto
|
|
|
|
* part.
|
2018-01-19 01:53:22 +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
|
|
|
* Returns 0 if OK, -1 on failure (adding a message to conn->errorMessage).
|
2018-01-19 01:53:22 +01:00
|
|
|
*/
|
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
|
|
|
extern int pgtls_init(PGconn *conn, bool do_ssl, bool do_crypto);
|
2018-01-19 01:53:22 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Begin or continue negotiating a secure session.
|
|
|
|
*/
|
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
|
|
|
extern PostgresPollingStatusType pgtls_open_client(PGconn *conn);
|
2018-01-19 01:53:22 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Close SSL connection.
|
|
|
|
*/
|
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
|
|
|
extern void pgtls_close(PGconn *conn);
|
2018-01-19 01:53:22 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Read data from a secure connection.
|
|
|
|
*
|
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
|
|
|
* On failure, this function is responsible for appending a suitable message
|
|
|
|
* to conn->errorMessage. The caller must still inspect errno, but only
|
2018-01-19 01:53:22 +01:00
|
|
|
* to determine whether to continue/retry after error.
|
|
|
|
*/
|
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
|
|
|
extern ssize_t pgtls_read(PGconn *conn, void *ptr, size_t len);
|
2018-01-19 01:53:22 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Is there unread data waiting in the SSL read buffer?
|
|
|
|
*/
|
2014-12-01 16:43:14 +01:00
|
|
|
extern bool pgtls_read_pending(PGconn *conn);
|
2018-01-19 01:53:22 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Write data to a secure connection.
|
|
|
|
*
|
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
|
|
|
* On failure, this function is responsible for appending a suitable message
|
|
|
|
* to conn->errorMessage. The caller must still inspect errno, but only
|
2018-01-19 01:53:22 +01:00
|
|
|
* to determine whether to continue/retry after error.
|
|
|
|
*/
|
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
|
|
|
extern ssize_t pgtls_write(PGconn *conn, const void *ptr, size_t len);
|
2018-01-19 01:53:22 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Get the hash of the server certificate, for SCRAM channel binding type
|
|
|
|
* tls-server-end-point.
|
|
|
|
*
|
|
|
|
* NULL is sent back to the caller in the event of an error, with an
|
|
|
|
* error message for the caller to consume.
|
|
|
|
*/
|
2018-01-04 21:18:39 +01:00
|
|
|
extern char *pgtls_get_peer_certificate_hash(PGconn *conn, size_t *len);
|
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
|
|
|
|
2018-01-27 19:47:52 +01:00
|
|
|
/*
|
|
|
|
* Verify that the server certificate matches the host name we connected to.
|
|
|
|
*
|
|
|
|
* The certificate's Common Name and Subject Alternative Names are considered.
|
|
|
|
*
|
|
|
|
* Returns 1 if the name matches, and 0 if it does not. On error, returns
|
|
|
|
* -1, and sets the libpq error message.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
extern int pgtls_verify_peer_name_matches_certificate_guts(PGconn *conn,
|
|
|
|
int *names_examined,
|
|
|
|
char **first_name);
|
|
|
|
|
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
|
|
|
/* === GSSAPI === */
|
|
|
|
|
|
|
|
#ifdef ENABLE_GSS
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Establish a GSSAPI-encrypted connection.
|
|
|
|
*/
|
|
|
|
extern PostgresPollingStatusType pqsecure_open_gss(PGconn *conn);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read and write functions for GSSAPI-encrypted connections, with internal
|
|
|
|
* buffering to handle nonblocking sockets.
|
|
|
|
*/
|
|
|
|
extern ssize_t pg_GSS_write(PGconn *conn, const void *ptr, size_t len);
|
|
|
|
extern ssize_t pg_GSS_read(PGconn *conn, void *ptr, size_t len);
|
|
|
|
#endif
|
|
|
|
|
2023-05-02 05:23:08 +02:00
|
|
|
/* === in fe-trace.c === */
|
2021-03-31 01:12:34 +02:00
|
|
|
|
|
|
|
extern void pqTraceOutputMessage(PGconn *conn, const char *message,
|
|
|
|
bool toServer);
|
|
|
|
extern void pqTraceOutputNoTypeByteMessage(PGconn *conn, const char *message);
|
|
|
|
|
2018-01-19 01:53:22 +01:00
|
|
|
/* === miscellaneous macros === */
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Reset the conn's error-reporting state.
|
|
|
|
*/
|
|
|
|
#define pqClearConnErrorState(conn) \
|
|
|
|
(resetPQExpBuffer(&(conn)->errorMessage), \
|
|
|
|
(conn)->errorReported = 0)
|
|
|
|
|
2022-04-21 23:12:49 +02:00
|
|
|
/*
|
|
|
|
* Check whether we have a PGresult pending to be returned --- either a
|
|
|
|
* constructed one in conn->result, or a "virtual" error result that we
|
|
|
|
* don't intend to materialize until the end of the query cycle.
|
|
|
|
*/
|
|
|
|
#define pgHavePendingResult(conn) \
|
|
|
|
((conn)->result != NULL || (conn)->error_result)
|
|
|
|
|
2000-01-18 07:09:24 +01:00
|
|
|
/*
|
2003-06-21 23:51:35 +02:00
|
|
|
* this is so that we can check if a connection is non-blocking internally
|
2000-01-18 07:09:24 +01:00
|
|
|
* without the overhead of a function call
|
|
|
|
*/
|
2001-01-21 00:07:27 +01:00
|
|
|
#define pqIsnonblocking(conn) ((conn)->nonblocking)
|
2000-01-18 07:09:24 +01:00
|
|
|
|
2021-03-15 22:13:42 +01:00
|
|
|
/*
|
|
|
|
* Connection's outbuffer threshold, for pipeline mode.
|
|
|
|
*/
|
|
|
|
#define OUTBUFFER_THRESHOLD 65536
|
|
|
|
|
2001-07-15 15:45:04 +02:00
|
|
|
#ifdef ENABLE_NLS
|
|
|
|
extern char *libpq_gettext(const char *msgid) pg_attribute_format_arg(1);
|
2014-09-12 16:12:11 +02:00
|
|
|
extern char *libpq_ngettext(const char *msgid, const char *msgid_plural, unsigned long n) pg_attribute_format_arg(1) pg_attribute_format_arg(2);
|
2001-07-15 15:45:04 +02:00
|
|
|
#else
|
|
|
|
#define libpq_gettext(x) (x)
|
2014-09-12 16:12:11 +02:00
|
|
|
#define libpq_ngettext(s, p, n) ((n) == 1 ? (s) : (p))
|
2001-07-15 15:45:04 +02:00
|
|
|
#endif
|
2022-08-25 20:46:58 +02:00
|
|
|
/*
|
|
|
|
* libpq code should use the above, not _(), since that would use the
|
|
|
|
* surrounding programs's message catalog.
|
|
|
|
*/
|
|
|
|
#undef _
|
2001-10-28 07:26:15 +01:00
|
|
|
|
2022-11-15 11:50:04 +01:00
|
|
|
extern void libpq_append_error(PQExpBuffer errorMessage, const char *fmt,...) pg_attribute_printf(2, 3);
|
|
|
|
extern void libpq_append_conn_error(PGconn *conn, const char *fmt,...) pg_attribute_printf(2, 3);
|
|
|
|
|
2001-11-02 21:51:27 +01:00
|
|
|
/*
|
|
|
|
* These macros are needed to let error-handling code be portable between
|
|
|
|
* Unix and Windows. (ugh)
|
|
|
|
*/
|
|
|
|
#ifdef WIN32
|
|
|
|
#define SOCK_ERRNO (WSAGetLastError())
|
|
|
|
#define SOCK_STRERROR winsock_strerror
|
2003-09-05 04:08:36 +02:00
|
|
|
#define SOCK_ERRNO_SET(e) WSASetLastError(e)
|
2001-11-02 21:51:27 +01:00
|
|
|
#else
|
|
|
|
#define SOCK_ERRNO errno
|
2018-09-26 18:35:57 +02:00
|
|
|
#define SOCK_STRERROR strerror_r
|
2004-05-31 20:42:40 +02:00
|
|
|
#define SOCK_ERRNO_SET(e) (errno = (e))
|
2001-11-02 21:51:27 +01:00
|
|
|
#endif
|
|
|
|
|
1998-08-17 05:52:36 +02:00
|
|
|
#endif /* LIBPQ_INT_H */
|