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.
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, 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
|
|
|
|
2002-08-18 03:35:40 +02:00
|
|
|
#include <time.h>
|
2002-10-03 19:09:42 +02:00
|
|
|
#ifndef WIN32
|
|
|
|
#include <sys/time.h>
|
|
|
|
#endif
|
2002-08-18 03:35:40 +02:00
|
|
|
|
2004-01-09 03:02:43 +01:00
|
|
|
#ifdef ENABLE_THREAD_SAFETY
|
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>
|
2004-01-09 03:02:43 +01:00
|
|
|
#endif
|
2003-06-14 19:49:54 +02:00
|
|
|
|
1999-08-31 03:37:37 +02:00
|
|
|
/* include stuff common to fe and be */
|
2003-06-08 19:43:00 +02:00
|
|
|
#include "getaddrinfo.h"
|
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 */
|
|
|
|
#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.
|
|
|
|
*/
|
2007-11-15 22:14:46 +01:00
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
void *value;
|
|
|
|
int length;
|
2009-06-11 16:49:15 +02:00
|
|
|
} gss_buffer_desc;
|
2007-07-23 12:16:54 +02:00
|
|
|
#endif
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* ENABLE_SSPI */
|
2007-07-23 12:16:54 +02:00
|
|
|
|
Break out OpenSSL-specific code to separate files.
This refactoring is in preparation for adding support for other SSL
implementations, with no user-visible effects. There are now two #defines,
USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which
is defined when building with any SSL implementation. Currently, OpenSSL is
the only implementation so the two #defines go together, but USE_SSL is
supposed to be used for implementation-independent code.
The libpq SSL code is changed to use a custom BIO, which does all the raw
I/O, like we've been doing in the backend for a long time. That makes it
possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids
a couple of syscall for each send(). Probably doesn't make much performance
difference in practice - the SSL encryption is expensive enough to mask the
effect - but it was a natural result of this refactoring.
Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by
Alvaro Herrera, Andreas Karlsson, Jeff Janes.
2014-08-11 10:54:19 +02:00
|
|
|
#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
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* USE_OPENSSL */
|
2009-06-23 20:13:23 +02:00
|
|
|
|
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
|
|
|
*/
|
1999-05-25 18:15:34 +02:00
|
|
|
typedef union pgresult_data PGresult_data;
|
1998-11-18 01:47:28 +01:00
|
|
|
|
1999-05-25 18:15:34 +02:00
|
|
|
union pgresult_data
|
|
|
|
{
|
|
|
|
PGresult_data *next; /* link to next block, or NULL */
|
|
|
|
char space[1]; /* dummy for accessing block as bytes */
|
|
|
|
};
|
1998-11-18 01:47:28 +01:00
|
|
|
|
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 */
|
|
|
|
|
1999-05-25 18:15:34 +02:00
|
|
|
typedef struct pgresAttValue
|
|
|
|
{
|
|
|
|
int len; /* length in bytes of the value */
|
2005-10-15 04:49:52 +02:00
|
|
|
char *value; /* actual value, plus terminating zero byte */
|
2005-11-22 19:17:34 +01: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 */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
char contents[FLEXIBLE_ARRAY_MEMBER]; /* value, nul-terminated */
|
2005-11-22 19:17:34 +01:00
|
|
|
} PGMessageField;
|
2003-06-21 23:51:35 +02:00
|
|
|
|
|
|
|
/* Fields needed for notice handling */
|
|
|
|
typedef struct
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
PQnoticeReceiver noticeRec; /* notice message receiver */
|
2003-06-21 23:51:35 +02:00
|
|
|
void *noticeRecArg;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
PQnoticeProcessor noticeProc; /* notice message processor */
|
2003-06-21 23:51:35 +02:00
|
|
|
void *noticeProcArg;
|
2005-11-22 19:17:34 +01:00
|
|
|
} PGNoticeHooks;
|
2003-06-21 23:51:35 +02:00
|
|
|
|
2008-09-17 06:31:08 +02:00
|
|
|
typedef struct PGEvent
|
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
PGEventProc proc; /* the function to call on events */
|
2008-09-17 06:31:08 +02:00
|
|
|
char *name; /* used only for error messages */
|
|
|
|
void *passThrough; /* pointer supplied at registration time */
|
|
|
|
void *data; /* optional state (instance) data */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
bool resultInitialized; /* T if RESULTCREATE/COPY succeeded */
|
2008-09-17 06:31:08 +02:00
|
|
|
} PGEvent;
|
|
|
|
|
1999-05-25 18:15:34 +02:00
|
|
|
struct pg_result
|
|
|
|
{
|
|
|
|
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;
|
1999-05-25 18:15:34 +02:00
|
|
|
ExecStatusType resultStatus;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
char cmdStatus[CMDSTATUS_LEN]; /* cmd status from the query */
|
1999-05-25 18:15:34 +02:00
|
|
|
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
|
|
|
/*
|
2005-10-15 04:49:52 +02: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;
|
2009-06-11 16:49:15 +02:00
|
|
|
PGEvent *events;
|
2008-09-17 06:31:08 +02:00
|
|
|
int nEvents;
|
2001-10-28 07:26:15 +01:00
|
|
|
int client_encoding; /* encoding id */
|
2000-03-15 00:59:23 +01:00
|
|
|
|
2003-04-24 23:16:45 +02:00
|
|
|
/*
|
|
|
|
* Error information (all NULL if not an error result). errMsg is the
|
2005-10-15 04:49:52 +02:00
|
|
|
* "overall" error message returned by PQresultErrorMessage. If we have
|
|
|
|
* per-field info then it is stored in a linked list.
|
2003-04-24 23:16:45 +02:00
|
|
|
*/
|
1999-05-25 18:15:34 +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
|
|
|
|
1999-05-25 18:15:34 +02:00
|
|
|
/* All NULL attributes in the query result point to this null string */
|
|
|
|
char null_field[1];
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Space management information. Note that attDescs and error stuff, if
|
|
|
|
* not null, point into allocated blocks. But tuples points to a
|
1999-05-25 18:15:34 +02: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 */
|
1999-05-25 18:15:34 +02:00
|
|
|
};
|
1998-09-03 04:10:56 +02:00
|
|
|
|
|
|
|
/* PGAsyncStatusType defines the state of the query-execution state machine */
|
1999-05-25 18:15:34 +02:00
|
|
|
typedef enum
|
|
|
|
{
|
2001-10-28 07:26:15 +01:00
|
|
|
PGASYNC_IDLE, /* nothing's happening, dude */
|
|
|
|
PGASYNC_BUSY, /* query in progress */
|
|
|
|
PGASYNC_READY, /* result ready for PQgetResult */
|
|
|
|
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 */
|
|
|
|
PGASYNC_COPY_BOTH /* Copy In/Out data transfer in progress */
|
2005-11-22 19:17:34 +01:00
|
|
|
} PGAsyncStatusType;
|
1998-09-03 04:10:56 +02:00
|
|
|
|
2004-10-19 00:00:42 +02:00
|
|
|
/* PGQueryClass tracks which query protocol we are now executing */
|
|
|
|
typedef enum
|
|
|
|
{
|
|
|
|
PGQUERY_SIMPLE, /* simple Query protocol (PQexec) */
|
|
|
|
PGQUERY_EXTENDED, /* full Extended protocol (PQexecParams) */
|
2006-08-18 21:52:39 +02:00
|
|
|
PGQUERY_PREPARE, /* Parse only (PQprepare) */
|
|
|
|
PGQUERY_DESCRIBE /* Describe Statement or Portal */
|
2005-11-22 19:17:34 +01:00
|
|
|
} PGQueryClass;
|
2004-10-19 00:00:42 +02:00
|
|
|
|
2019-08-05 05:14:58 +02:00
|
|
|
/* PGSetenvStatusType defines the state of the pqSetenv state machine */
|
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/* (this is used only for 2.0-protocol connections) */
|
|
|
|
typedef enum
|
|
|
|
{
|
2011-02-19 07:54:58 +01:00
|
|
|
SETENV_STATE_CLIENT_ENCODING_SEND, /* About to send an Environment Option */
|
|
|
|
SETENV_STATE_CLIENT_ENCODING_WAIT, /* Waiting for above send to complete */
|
2003-06-08 19:43:00 +02:00
|
|
|
SETENV_STATE_OPTION_SEND, /* About to send an Environment Option */
|
|
|
|
SETENV_STATE_OPTION_WAIT, /* Waiting for above send to complete */
|
|
|
|
SETENV_STATE_QUERY1_SEND, /* About to send a status query */
|
|
|
|
SETENV_STATE_QUERY1_WAIT, /* Waiting for query to complete */
|
|
|
|
SETENV_STATE_QUERY2_SEND, /* About to send a status query */
|
|
|
|
SETENV_STATE_QUERY2_WAIT, /* Waiting for query to complete */
|
|
|
|
SETENV_STATE_IDLE
|
2005-11-22 19:17:34 +01:00
|
|
|
} PGSetenvStatusType;
|
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 */
|
2005-11-22 19:17:34 +01:00
|
|
|
} PQEnvironmentOption;
|
2003-06-08 19:43:00 +02:00
|
|
|
|
|
|
|
/* Typedef for parameter-status list entries */
|
|
|
|
typedef struct pgParameterStatus
|
|
|
|
{
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
struct pgParameterStatus *next; /* list link */
|
2003-06-08 19:43:00 +02:00
|
|
|
char *name; /* parameter name */
|
|
|
|
char *value; /* parameter value */
|
|
|
|
/* Note: name and value are stored in same malloc block as struct is */
|
2005-11-22 19:17:34 +01:00
|
|
|
} pgParameterStatus;
|
2003-06-08 19:43:00 +02:00
|
|
|
|
1998-09-03 04:10:56 +02:00
|
|
|
/* large-object-access data ... allocated only if large-object code is used. */
|
1999-05-25 18:15:34 +02:00
|
|
|
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 */
|
1999-05-25 18:15:34 +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 */
|
1999-05-25 18:15:34 +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-11-15 22:14:46 +01:00
|
|
|
Oid fn_lo_truncate; /* OID of backend function lo_truncate */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
Oid fn_lo_truncate64; /* OID of function lo_truncate64 */
|
1999-05-25 18:15:34 +02:00
|
|
|
Oid fn_lo_read; /* OID of backend function LOread */
|
|
|
|
Oid fn_lo_write; /* OID of backend function LOwrite */
|
2005-11-22 19:17:34 +01:00
|
|
|
} PGlobjfuncs;
|
1998-09-03 04:10:56 +02:00
|
|
|
|
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;
|
|
|
|
|
|
|
|
/*
|
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.
|
|
|
|
*/
|
1999-05-25 18:15:34 +02:00
|
|
|
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 */
|
1999-05-25 18:15:34 +02:00
|
|
|
char *pgtty; /* tty on which the backend messages is
|
2003-04-22 02:08:07 +02:00
|
|
|
* displayed (OBSOLETE, NOT USED) */
|
2003-08-04 02:43:34 +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) */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
char *client_encoding_initial; /* encoding to use */
|
1999-05-25 18:15:34 +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 */
|
1999-05-25 18:15:34 +02:00
|
|
|
char *dbName; /* database name */
|
2010-01-15 10:19:10 +01:00
|
|
|
char *replication; /* connect as the replication standby? */
|
1999-05-25 18:15:34 +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 */
|
2010-07-06 21:19:02 +02:00
|
|
|
char *keepalives_interval; /* time between TCP keepalive
|
|
|
|
* retransmits */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
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) */
|
2012-06-10 21:20:04 +02: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 */
|
2008-12-15 11:28:22 +01:00
|
|
|
char *sslrootcert; /* root certificate filename */
|
|
|
|
char *sslcrl; /* certificate revocation list filename */
|
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-10-15 04:49:52 +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") */
|
2020-01-28 02:40:48 +01:00
|
|
|
char *sslminprotocolversion; /* minimum TLS protocol version */
|
|
|
|
char *sslmaxprotocolversion; /* maximum TLS protocol version */
|
1999-05-25 18:15:34 +02:00
|
|
|
|
2017-05-17 02:36:35 +02:00
|
|
|
/* Type of connection to make. Possible values: any, read-write. */
|
|
|
|
char *target_session_attrs;
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
|
1999-05-25 18:15:34 +02:00
|
|
|
/* Optional file to write trace info to */
|
|
|
|
FILE *Pfdebug;
|
|
|
|
|
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 */
|
2009-06-11 16:49:15 +02:00
|
|
|
PGEvent *events; /* expandable array of event data */
|
2008-09-17 06:31:08 +02:00
|
|
|
int nEvents; /* number of active events */
|
2009-06-11 16:49:15 +02:00
|
|
|
int eventArraySize; /* allocated array size */
|
2008-09-17 06:31:08 +02:00
|
|
|
|
1999-05-25 18:15:34 +02:00
|
|
|
/* Status indicators */
|
|
|
|
ConnStatusType status;
|
|
|
|
PGAsyncStatusType asyncStatus;
|
2006-10-04 02:30:14 +02:00
|
|
|
PGTransactionStatusType xactStatus; /* never changes to ACTIVE */
|
2004-10-19 00:00:42 +02:00
|
|
|
PGQueryClass queryclass;
|
2006-03-14 23:48:25 +01:00
|
|
|
char *last_query; /* last SQL command, or NULL if unknown */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02: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 */
|
2005-10-15 04:49:52 +02:00
|
|
|
bool nonblocking; /* whether this connection is using nonblock
|
|
|
|
* sending semantics */
|
2012-08-02 19:10:30 +02:00
|
|
|
bool singleRowMode; /* return current query result row-by-row? */
|
2003-08-04 02:43:34 +02:00
|
|
|
char copy_is_binary; /* 1 = copy binary, 0 = copy text */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
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
|
|
|
|
1999-05-25 18:15:34 +02:00
|
|
|
/* Connection data */
|
2014-05-06 18:12:18 +02:00
|
|
|
pgsocket sock; /* FD for socket, PGINVALID_SOCKET if
|
|
|
|
* unconnected */
|
1999-05-25 18:15:34 +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 */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02: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 */
|
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
|
|
|
|
|
|
|
/* Transient state needed while establishing connection */
|
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[]? */
|
In libpq, don't look up all the hostnames at once.
Historically, we looked up the target hostname in connectDBStart, so that
PQconnectPoll did not need to do DNS name resolution. The patches that
added multiple-target-host support to libpq preserved this division of
labor; but it's really nonsensical now, because it means that if any one
of the target hosts fails to resolve in DNS, the connection fails. That
negates the no-single-point-of-failure goal of the feature. Additionally,
DNS lookups aren't exactly cheap, but the code did them all even if the
first connection attempt succeeds.
Hence, rearrange so that PQconnectPoll does the lookups, and only looks
up a hostname when it's time to try that host. This does mean that
PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid
that, you should be using hostaddr, as the documentation has always
specified. It seems fairly unlikely that any applications would really
care whether the lookup occurs inside PQconnectStart or PQconnectPoll.
In addition to calling out that fact explicitly, do some other minor
wordsmithing in the docs around the multiple-target-host feature.
Since this seems like a bug in the multiple-target-host feature,
backpatch to v10 where that was introduced. In the back branches,
avoid moving any existing fields of struct pg_conn, just in case
any third-party code is looking into that struct.
Tom Lane, reviewed by Fabien Coelho
Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
2018-08-23 22:39:19 +02:00
|
|
|
struct addrinfo *addrlist; /* list of addresses for current connhost */
|
|
|
|
struct addrinfo *addr_cur; /* the one currently being tried */
|
|
|
|
int addrlist_family; /* needed to know how to free addrlist */
|
2003-08-04 02:43:34 +02:00
|
|
|
PGSetenvStatusType setenv_state; /* for 2.0 protocol only */
|
2003-06-08 19:43:00 +02:00
|
|
|
const PQEnvironmentOption *next_eo;
|
2009-12-02 05:38:35 +01:00
|
|
|
bool send_appname; /* okay to send application_name? */
|
1999-05-25 18:15:34 +02:00
|
|
|
|
|
|
|
/* Miscellaneous stuff */
|
|
|
|
int be_pid; /* PID of backend --- needed for cancels */
|
|
|
|
int be_key; /* key of backend --- needed for cancels */
|
2003-08-04 02:43:34 +02:00
|
|
|
pgParameterStatus *pstatus; /* ParameterStatus data */
|
|
|
|
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 */
|
2003-08-04 02:43:34 +02:00
|
|
|
PGVerbosity verbosity; /* error/notice message verbosity */
|
2015-09-05 17:58:20 +02:00
|
|
|
PGContextVisibility show_context; /* whether to show CONTEXT field */
|
2005-10-15 04:49:52 +02:00
|
|
|
PGlobjfuncs *lobjfuncs; /* private state for large-object access fns */
|
1999-05-25 18:15:34 +02:00
|
|
|
|
|
|
|
/* Buffer for data received from backend and not yet processed */
|
|
|
|
char *inBuffer; /* currently allocated buffer */
|
|
|
|
int inBufSize; /* allocated size of buffer */
|
2005-10-15 04:49:52 +02:00
|
|
|
int inStart; /* offset to first unconsumed data in buffer */
|
1999-05-25 18:15:34 +02:00
|
|
|
int inCursor; /* next byte to tentatively consume */
|
2005-10-15 04:49:52 +02:00
|
|
|
int inEnd; /* offset to first position after avail data */
|
1999-05-25 18:15:34 +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 */
|
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
/* State for constructing messages in outBuffer */
|
2005-10-15 04:49:52 +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 */
|
|
|
|
|
1999-05-25 18:15:34 +02:00
|
|
|
/* Status for asynchronous result construction */
|
|
|
|
PGresult *result; /* result being constructed */
|
2012-08-02 19:10:30 +02:00
|
|
|
PGresult *next_result; /* next result (used in single-row mode) */
|
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 */
|
|
|
|
void *sasl_state;
|
1999-05-25 18:15:34 +02:00
|
|
|
|
2017-11-18 16:07:57 +01:00
|
|
|
/* SSL structures */
|
|
|
|
bool ssl_in_use;
|
|
|
|
|
1999-09-27 05:13:16 +02:00
|
|
|
#ifdef USE_SSL
|
2000-04-12 19:17:23 +02: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-04-12 19:17:23 +02: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
|
2010-02-26 03:01:40 +01:00
|
|
|
void *engine; /* dummy field to keep struct the same if
|
|
|
|
* OpenSSL version changes */
|
1999-09-27 05:13:16 +02:00
|
|
|
#endif
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* USE_OPENSSL */
|
|
|
|
#endif /* USE_SSL */
|
1999-09-27 05:13:16 +02:00
|
|
|
|
2007-07-10 15:14:22 +02:00
|
|
|
#ifdef ENABLE_GSS
|
2007-11-15 22:14:46 +01:00
|
|
|
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 */
|
|
|
|
int gss_SendConsumed; /* Number of *unencrypted* bytes consumed
|
|
|
|
* for current contents of gss_SendBuffer */
|
|
|
|
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
|
2007-11-15 22:14:46 +01:00
|
|
|
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 */
|
2007-07-23 12:16:54 +02:00
|
|
|
#endif
|
|
|
|
|
1999-08-31 03:37:37 +02:00
|
|
|
/* Buffer for current error message */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
PQExpBufferData errorMessage; /* expansible string */
|
1999-08-31 03:37:37 +02:00
|
|
|
|
|
|
|
/* Buffer for receiving various parts of messages */
|
2000-04-12 19:17:23 +02:00
|
|
|
PQExpBufferData workBuffer; /* expansible string */
|
1999-05-25 18:15:34 +02:00
|
|
|
};
|
1998-09-03 04:10:56 +02:00
|
|
|
|
2004-10-31 01:11:27 +02:00
|
|
|
/* PGcancel stores all data necessary to cancel a connection. A copy of this
|
|
|
|
* data is required to safely cancel a connection running on a different
|
|
|
|
* thread.
|
|
|
|
*/
|
|
|
|
struct pg_cancel
|
|
|
|
{
|
|
|
|
SockAddr raddr; /* Remote address */
|
|
|
|
int be_pid; /* PID of backend --- needed for cancels */
|
|
|
|
int be_key; /* key of backend --- needed for cancels */
|
|
|
|
};
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* USE_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
|
|
|
|
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);
|
2019-05-22 19:04:48 +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);
|
1998-08-17 05:52:36 +02:00
|
|
|
|
2004-03-24 04:45:00 +01:00
|
|
|
#ifdef ENABLE_THREAD_SAFETY
|
2004-12-03 00:20:21 +01:00
|
|
|
extern pgthreadlock_t pg_g_threadlock;
|
2004-08-29 07:07:03 +02:00
|
|
|
|
2008-05-16 20:30:53 +02:00
|
|
|
#define PGTHREAD_ERROR(msg) \
|
|
|
|
do { \
|
|
|
|
fprintf(stderr, "%s\n", msg); \
|
2012-01-30 20:34:00 +01:00
|
|
|
abort(); \
|
2008-05-16 20:30:53 +02:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
2004-12-03 00:20:21 +01:00
|
|
|
#define pglock_thread() pg_g_threadlock(true)
|
|
|
|
#define pgunlock_thread() pg_g_threadlock(false)
|
2004-03-24 04:45:00 +01:00
|
|
|
#else
|
2004-12-03 00:20:21 +01:00
|
|
|
#define pglock_thread() ((void) 0)
|
|
|
|
#define pgunlock_thread() ((void) 0)
|
2004-03-24 04:45:00 +01:00
|
|
|
#endif
|
2004-08-29 07:07:03 +02:00
|
|
|
|
1998-08-17 05:52:36 +02:00
|
|
|
/* === in fe-exec.c === */
|
|
|
|
|
1998-10-01 03:40:26 +02:00
|
|
|
extern void pqSetResultError(PGresult *res, const char *msg);
|
2003-06-08 19:43:00 +02:00
|
|
|
extern void pqCatenateResultError(PGresult *res, const char *msg);
|
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);
|
1999-05-25 18:15:34 +02:00
|
|
|
extern char *pqResultStrdup(PGresult *res, const char *str);
|
1998-09-01 06:40:42 +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);
|
2015-03-26 19:03:19 +01: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,
|
2019-05-22 19:04:48 +02:00
|
|
|
const char *value);
|
2003-06-08 19:43:00 +02:00
|
|
|
extern void pqSaveParameterStatus(PGconn *conn, const char *name,
|
2019-05-22 19:04:48 +02:00
|
|
|
const char *value);
|
2012-08-02 19:10:30 +02:00
|
|
|
extern int pqRowProcessor(PGconn *conn, const char **errmsgp);
|
2003-06-08 19:43:00 +02:00
|
|
|
|
|
|
|
/* === in fe-protocol2.c === */
|
|
|
|
|
|
|
|
extern PostgresPollingStatusType pqSetenvPoll(PGconn *conn);
|
|
|
|
|
|
|
|
extern char *pqBuildStartupPacket2(PGconn *conn, int *packetlen,
|
2019-05-22 19:04:48 +02:00
|
|
|
const PQEnvironmentOption *options);
|
2003-06-08 19:43:00 +02:00
|
|
|
extern void pqParseInput2(PGconn *conn);
|
2003-06-21 23:51:35 +02:00
|
|
|
extern int pqGetCopyData2(PGconn *conn, char **buffer, int async);
|
2003-06-08 19:43:00 +02:00
|
|
|
extern int pqGetline2(PGconn *conn, char *s, int maxlen);
|
|
|
|
extern int pqGetlineAsync2(PGconn *conn, char *buffer, int bufsize);
|
|
|
|
extern int pqEndcopy2(PGconn *conn);
|
|
|
|
extern PGresult *pqFunctionCall2(PGconn *conn, Oid fnid,
|
2019-05-22 19:04:48 +02:00
|
|
|
int *result_buf, int *actual_result_len,
|
|
|
|
int result_is_int,
|
|
|
|
const PQArgBlock *args, int nargs);
|
2003-06-08 19:43:00 +02:00
|
|
|
|
|
|
|
/* === in fe-protocol3.c === */
|
|
|
|
|
|
|
|
extern char *pqBuildStartupPacket3(PGconn *conn, int *packetlen,
|
2019-05-22 19:04:48 +02:00
|
|
|
const PQEnvironmentOption *options);
|
2003-06-08 19:43:00 +02:00
|
|
|
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,
|
2019-05-22 19:04:48 +02:00
|
|
|
PGVerbosity verbosity, PGContextVisibility show_context);
|
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,
|
2019-05-22 19:04:48 +02:00
|
|
|
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 === */
|
|
|
|
|
1998-09-01 06:40:42 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* "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
|
1998-09-01 06:40:42 +02:00
|
|
|
* 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-09-01 06:40:42 +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-09-01 06:40:42 +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);
|
2003-06-08 19:43:00 +02:00
|
|
|
extern int pqPutMsgStart(char msg_type, bool force_len, PGconn *conn);
|
2003-04-19 02:02:30 +02:00
|
|
|
extern int pqPutMsgEnd(PGconn *conn);
|
1998-09-01 06:40:42 +02:00
|
|
|
extern int pqReadData(PGconn *conn);
|
|
|
|
extern int pqFlush(PGconn *conn);
|
|
|
|
extern int pqWait(int forRead, int forWrite, PGconn *conn);
|
2019-05-22 19:04:48 +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 === */
|
|
|
|
|
2002-09-04 22:31:48 +02:00
|
|
|
extern int pqsecure_initialize(PGconn *);
|
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
|
|
|
|
2005-08-23 23:02:05 +02:00
|
|
|
#if defined(ENABLE_THREAD_SAFETY) && !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,
|
2019-05-22 19:04:48 +02:00
|
|
|
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
|
|
|
|
* message - no connection-local setup is made here.
|
|
|
|
*
|
|
|
|
* Returns 0 if OK, -1 on failure (with a message in conn->errorMessage).
|
|
|
|
*/
|
2015-02-21 07:46:43 +01:00
|
|
|
extern int pgtls_init(PGconn *conn);
|
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.
|
|
|
|
*
|
|
|
|
* On failure, this function is responsible for putting a suitable message
|
|
|
|
* into conn->errorMessage. The caller must still inspect errno, but only
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* On failure, this function is responsible for putting a suitable message
|
|
|
|
* into conn->errorMessage. The caller must still inspect errno, but only
|
|
|
|
* 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.
|
Remove support for tls-unique channel binding.
There are some problems with the tls-unique channel binding type. It's not
supported by all SSL libraries, and strictly speaking it's not defined for
TLS 1.3 at all, even though at least in OpenSSL, the functions used for it
still seem to work with TLS 1.3 connections. And since we had no
mechanism to negotiate what channel binding type to use, there would be
awkward interoperability issues if a server only supported some channel
binding types. tls-server-end-point seems feasible to support with any SSL
library, so let's just stick to that.
This removes the scram_channel_binding libpq option altogether, since there
is now only one supported channel binding type.
This also removes all the channel binding tests from the SSL test suite.
They were really just testing the scram_channel_binding option, which
is now gone. Channel binding is used if both client and server support it,
so it is used in the existing tests. It would be good to have some tests
specifically for channel binding, to make sure it really is used, and the
different combinations of a client and a server that support or doesn't
support it. The current set of settings we have make it hard to write such
tests, but I did test those things manually, by disabling
HAVE_BE_TLS_GET_CERTIFICATE_HASH and/or
HAVE_PGTLS_GET_PEER_CERTIFICATE_HASH.
I also removed the SCRAM_CHANNEL_BINDING_TLS_END_POINT constant. This is a
matter of taste, but IMO it's more readable to just use the
"tls-server-end-point" string.
Refactor the checks on whether the SSL library supports the functions
needed for tls-server-end-point channel binding. Now the server won't
advertise, and the client won't choose, the SCRAM-SHA-256-PLUS variant, if
compiled with an OpenSSL version too old to support it.
In the passing, add some sanity checks to check that the chosen SASL
mechanism, SCRAM-SHA-256 or SCRAM-SHA-256-PLUS, matches whether the SCRAM
exchange used channel binding or not. For example, if the client selects
the non-channel-binding variant SCRAM-SHA-256, but in the SCRAM message
uses channel binding anyway. It's harmless from a security point of view,
I believe, and I'm not sure if there are some other conditions that would
cause the connection to fail, but it seems better to be strict about these
things and check explicitly.
Discussion: https://www.postgresql.org/message-id/ec787074-2305-c6f4-86aa-6902f98485a4%40iki.fi
2018-08-05 12:44:21 +02:00
|
|
|
*
|
|
|
|
* This is not supported with old versions of OpenSSL that don't have
|
|
|
|
* the X509_get_signature_nid() function.
|
2018-01-19 01:53:22 +01:00
|
|
|
*/
|
Remove support for tls-unique channel binding.
There are some problems with the tls-unique channel binding type. It's not
supported by all SSL libraries, and strictly speaking it's not defined for
TLS 1.3 at all, even though at least in OpenSSL, the functions used for it
still seem to work with TLS 1.3 connections. And since we had no
mechanism to negotiate what channel binding type to use, there would be
awkward interoperability issues if a server only supported some channel
binding types. tls-server-end-point seems feasible to support with any SSL
library, so let's just stick to that.
This removes the scram_channel_binding libpq option altogether, since there
is now only one supported channel binding type.
This also removes all the channel binding tests from the SSL test suite.
They were really just testing the scram_channel_binding option, which
is now gone. Channel binding is used if both client and server support it,
so it is used in the existing tests. It would be good to have some tests
specifically for channel binding, to make sure it really is used, and the
different combinations of a client and a server that support or doesn't
support it. The current set of settings we have make it hard to write such
tests, but I did test those things manually, by disabling
HAVE_BE_TLS_GET_CERTIFICATE_HASH and/or
HAVE_PGTLS_GET_PEER_CERTIFICATE_HASH.
I also removed the SCRAM_CHANNEL_BINDING_TLS_END_POINT constant. This is a
matter of taste, but IMO it's more readable to just use the
"tls-server-end-point" string.
Refactor the checks on whether the SSL library supports the functions
needed for tls-server-end-point channel binding. Now the server won't
advertise, and the client won't choose, the SCRAM-SHA-256-PLUS variant, if
compiled with an OpenSSL version too old to support it.
In the passing, add some sanity checks to check that the chosen SASL
mechanism, SCRAM-SHA-256 or SCRAM-SHA-256-PLUS, matches whether the SCRAM
exchange used channel binding or not. For example, if the client selects
the non-channel-binding variant SCRAM-SHA-256, but in the SCRAM message
uses channel binding anyway. It's harmless from a security point of view,
I believe, and I'm not sure if there are some other conditions that would
cause the connection to fail, but it seems better to be strict about these
things and check explicitly.
Discussion: https://www.postgresql.org/message-id/ec787074-2305-c6f4-86aa-6902f98485a4%40iki.fi
2018-08-05 12:44:21 +02:00
|
|
|
#if defined(USE_OPENSSL) && defined(HAVE_X509_GET_SIGNATURE_NID)
|
|
|
|
#define HAVE_PGTLS_GET_PEER_CERTIFICATE_HASH
|
2018-01-04 21:18:39 +01:00
|
|
|
extern char *pgtls_get_peer_certificate_hash(PGconn *conn, size_t *len);
|
Remove support for tls-unique channel binding.
There are some problems with the tls-unique channel binding type. It's not
supported by all SSL libraries, and strictly speaking it's not defined for
TLS 1.3 at all, even though at least in OpenSSL, the functions used for it
still seem to work with TLS 1.3 connections. And since we had no
mechanism to negotiate what channel binding type to use, there would be
awkward interoperability issues if a server only supported some channel
binding types. tls-server-end-point seems feasible to support with any SSL
library, so let's just stick to that.
This removes the scram_channel_binding libpq option altogether, since there
is now only one supported channel binding type.
This also removes all the channel binding tests from the SSL test suite.
They were really just testing the scram_channel_binding option, which
is now gone. Channel binding is used if both client and server support it,
so it is used in the existing tests. It would be good to have some tests
specifically for channel binding, to make sure it really is used, and the
different combinations of a client and a server that support or doesn't
support it. The current set of settings we have make it hard to write such
tests, but I did test those things manually, by disabling
HAVE_BE_TLS_GET_CERTIFICATE_HASH and/or
HAVE_PGTLS_GET_PEER_CERTIFICATE_HASH.
I also removed the SCRAM_CHANNEL_BINDING_TLS_END_POINT constant. This is a
matter of taste, but IMO it's more readable to just use the
"tls-server-end-point" string.
Refactor the checks on whether the SSL library supports the functions
needed for tls-server-end-point channel binding. Now the server won't
advertise, and the client won't choose, the SCRAM-SHA-256-PLUS variant, if
compiled with an OpenSSL version too old to support it.
In the passing, add some sanity checks to check that the chosen SASL
mechanism, SCRAM-SHA-256 or SCRAM-SHA-256-PLUS, matches whether the SCRAM
exchange used channel binding or not. For example, if the client selects
the non-channel-binding variant SCRAM-SHA-256, but in the SCRAM message
uses channel binding anyway. It's harmless from a security point of view,
I believe, and I'm not sure if there are some other conditions that would
cause the connection to fail, but it seems better to be strict about these
things and check explicitly.
Discussion: https://www.postgresql.org/message-id/ec787074-2305-c6f4-86aa-6902f98485a4%40iki.fi
2018-08-05 12:44:21 +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
|
|
|
|
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.
|
|
|
|
*
|
|
|
|
*/
|
2019-05-22 19:04:48 +02:00
|
|
|
extern int pgtls_verify_peer_name_matches_certificate_guts(PGconn *conn,
|
|
|
|
int *names_examined,
|
|
|
|
char **first_name);
|
2018-01-27 19:47:52 +01:00
|
|
|
|
GSSAPI encryption support
On both the frontend and backend, prepare for GSSAPI encryption
support by moving common code for error handling into a separate file.
Fix a TODO for handling multiple status messages in the process.
Eliminate the OIDs, which have not been needed for some time.
Add frontend and backend encryption support functions. Keep the
context initiation for authentication-only separate on both the
frontend and backend in order to avoid concerns about changing the
requested flags to include encryption support.
In postmaster, pull GSSAPI authorization checking into a shared
function. Also share the initiator name between the encryption and
non-encryption codepaths.
For HBA, add "hostgssenc" and "hostnogssenc" entries that behave
similarly to their SSL counterparts. "hostgssenc" requires either
"gss", "trust", or "reject" for its authentication.
Similarly, add a "gssencmode" parameter to libpq. Supported values are
"disable", "require", and "prefer". Notably, negotiation will only be
attempted if credentials can be acquired. Move credential acquisition
into its own function to support this behavior.
Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring
if GSSAPI authentication was used, what principal was used, and if
encryption is being used on the connection.
Finally, add documentation for everything new, and update existing
documentation on connection security.
Thanks to Michael Paquier for the Windows fixes.
Author: Robbie Harwood, with changes to the read/write functions by me.
Reviewed in various forms and at different times by: Michael Paquier,
Andres Freund, David Steele.
Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
|
|
|
/* === 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
|
|
|
|
|
2018-01-19 01:53:22 +01:00
|
|
|
/* === miscellaneous macros === */
|
|
|
|
|
2000-04-12 19:17:23 +02: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
|
|
|
|
2001-07-15 15:45:04 +02:00
|
|
|
#ifdef ENABLE_NLS
|
2015-03-26 19:03:19 +01:00
|
|
|
extern char *libpq_gettext(const char *msgid) pg_attribute_format_arg(1);
|
|
|
|
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
|
2001-10-28 07:26:15 +01:00
|
|
|
|
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
|
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* LIBPQ_INT_H */
|