1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* pqcomm.h
|
1998-01-26 02:42:53 +01:00
|
|
|
* Definitions common to frontends and backends.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1999-04-25 05:19:27 +02:00
|
|
|
* NOTE: for historical reasons, this does not correspond to pqcomm.c.
|
|
|
|
* pqcomm.c's routines are declared in libpq.h.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2022-01-08 01:04:57 +01:00
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/libpq/pqcomm.h
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef PQCOMM_H
|
|
|
|
#define PQCOMM_H
|
|
|
|
|
2000-09-27 17:17:57 +02:00
|
|
|
#include <sys/socket.h>
|
2003-01-06 06:33:45 +01:00
|
|
|
#include <netdb.h>
|
2000-09-27 17:17:57 +02:00
|
|
|
#ifdef HAVE_SYS_UN_H
|
|
|
|
#include <sys/un.h>
|
|
|
|
#endif
|
|
|
|
#include <netinet/in.h>
|
|
|
|
|
2003-07-24 01:30:41 +02:00
|
|
|
#ifdef HAVE_STRUCT_SOCKADDR_STORAGE
|
2000-09-27 17:17:57 +02:00
|
|
|
|
2003-07-24 01:30:41 +02:00
|
|
|
#ifndef HAVE_STRUCT_SOCKADDR_STORAGE_SS_FAMILY
|
|
|
|
#ifdef HAVE_STRUCT_SOCKADDR_STORAGE___SS_FAMILY
|
|
|
|
#define ss_family __ss_family
|
|
|
|
#else
|
|
|
|
#error struct sockaddr_storage does not provide an ss_family member
|
|
|
|
#endif
|
2003-06-24 03:49:22 +02:00
|
|
|
#endif
|
|
|
|
|
2003-07-24 01:30:41 +02:00
|
|
|
#ifdef HAVE_STRUCT_SOCKADDR_STORAGE___SS_LEN
|
|
|
|
#define ss_len __ss_len
|
|
|
|
#define HAVE_STRUCT_SOCKADDR_STORAGE_SS_LEN 1
|
2003-07-15 19:54:34 +02:00
|
|
|
#endif
|
2003-07-24 01:30:41 +02:00
|
|
|
#else /* !HAVE_STRUCT_SOCKADDR_STORAGE */
|
2003-01-06 10:58:36 +01:00
|
|
|
|
2003-07-24 01:30:41 +02:00
|
|
|
/* Define a struct sockaddr_storage if we don't have one. */
|
2003-07-15 19:54:34 +02:00
|
|
|
|
2003-07-24 01:30:41 +02:00
|
|
|
struct sockaddr_storage
|
|
|
|
{
|
|
|
|
union
|
|
|
|
{
|
|
|
|
struct sockaddr sa; /* get the system-dependent fields */
|
|
|
|
int64 ss_align; /* ensures struct is properly aligned */
|
|
|
|
char ss_pad[128]; /* ensures struct has desired size */
|
|
|
|
} ss_stuff;
|
2000-09-27 17:17:57 +02:00
|
|
|
};
|
2003-07-15 19:54:34 +02:00
|
|
|
|
2003-07-24 01:30:41 +02:00
|
|
|
#define ss_family ss_stuff.sa.sa_family
|
|
|
|
/* It should have an ss_len field if sockaddr has sa_len. */
|
|
|
|
#ifdef HAVE_STRUCT_SOCKADDR_SA_LEN
|
|
|
|
#define ss_len ss_stuff.sa.sa_len
|
|
|
|
#define HAVE_STRUCT_SOCKADDR_STORAGE_SS_LEN 1
|
1998-08-29 06:05:46 +02:00
|
|
|
#endif
|
2003-07-24 01:30:41 +02:00
|
|
|
#endif /* HAVE_STRUCT_SOCKADDR_STORAGE */
|
1998-01-26 02:42:53 +01:00
|
|
|
|
2003-06-12 09:36:51 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
struct sockaddr_storage addr;
|
2021-11-09 15:20:47 +01:00
|
|
|
socklen_t salen;
|
1998-01-26 02:42:53 +01:00
|
|
|
} SockAddr;
|
|
|
|
|
2000-12-01 00:19:04 +01:00
|
|
|
/* Configure the UNIX socket location for the well known port. */
|
1998-03-02 06:42:15 +01:00
|
|
|
|
2006-05-17 03:44:24 +02:00
|
|
|
#define UNIXSOCK_PATH(path, port, sockdir) \
|
2020-01-31 16:26:12 +01:00
|
|
|
(AssertMacro(sockdir), \
|
|
|
|
AssertMacro(*(sockdir) != '\0'), \
|
2003-06-12 09:36:51 +02:00
|
|
|
snprintf(path, sizeof(path), "%s/.s.PGSQL.%d", \
|
2020-01-31 16:26:12 +01:00
|
|
|
(sockdir), (port)))
|
2000-11-22 04:40:19 +01:00
|
|
|
|
2012-11-30 01:57:01 +01:00
|
|
|
/*
|
|
|
|
* The maximum workable length of a socket path is what will fit into
|
|
|
|
* struct sockaddr_un. This is usually only 100 or so bytes :-(.
|
|
|
|
*
|
|
|
|
* For consistency, always pass a MAXPGPATH-sized buffer to UNIXSOCK_PATH(),
|
|
|
|
* then complain if the resulting string is >= UNIXSOCK_PATH_BUFLEN bytes.
|
|
|
|
* (Because the standard API for getaddrinfo doesn't allow it to complain in
|
|
|
|
* a useful way when the socket pathname is too long, we have to test for
|
|
|
|
* this explicitly, instead of just letting the subroutine return an error.)
|
|
|
|
*/
|
|
|
|
#define UNIXSOCK_PATH_BUFLEN sizeof(((struct sockaddr_un *) NULL)->sun_path)
|
|
|
|
|
2020-11-25 08:14:23 +01:00
|
|
|
/*
|
|
|
|
* A host that looks either like an absolute path or starts with @ is
|
|
|
|
* interpreted as a Unix-domain socket address.
|
|
|
|
*/
|
|
|
|
static inline bool
|
|
|
|
is_unixsock_path(const char *path)
|
|
|
|
{
|
|
|
|
return is_absolute_path(path) || path[0] == '@';
|
|
|
|
}
|
2012-11-30 01:57:01 +01:00
|
|
|
|
1998-01-26 02:42:53 +01:00
|
|
|
/*
|
|
|
|
* These manipulate the frontend/backend protocol version number.
|
|
|
|
*
|
|
|
|
* The major number should be incremented for incompatible changes. The minor
|
|
|
|
* number should be incremented for compatible changes (eg. additional
|
|
|
|
* functionality).
|
|
|
|
*
|
|
|
|
* If a backend supports version m.n of the protocol it must actually support
|
2003-04-18 00:26:02 +02:00
|
|
|
* versions m.[0..n]. Backend support for version m-1 can be dropped after a
|
1998-01-26 02:42:53 +01:00
|
|
|
* `reasonable' length of time.
|
|
|
|
*
|
|
|
|
* A frontend isn't required to support anything other than the current
|
|
|
|
* version.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define PG_PROTOCOL_MAJOR(v) ((v) >> 16)
|
|
|
|
#define PG_PROTOCOL_MINOR(v) ((v) & 0x0000ffff)
|
|
|
|
#define PG_PROTOCOL(m,n) (((m) << 16) | (n))
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2021-03-04 09:45:55 +01:00
|
|
|
/*
|
|
|
|
* The earliest and latest frontend/backend protocol version supported.
|
|
|
|
* (Only protocol version 3 is currently supported)
|
|
|
|
*/
|
1998-01-26 02:42:53 +01:00
|
|
|
|
2021-03-04 09:45:55 +01:00
|
|
|
#define PG_PROTOCOL_EARLIEST PG_PROTOCOL(3,0)
|
2003-05-08 20:33:39 +02:00
|
|
|
#define PG_PROTOCOL_LATEST PG_PROTOCOL(3,0)
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-04-18 00:26:02 +02:00
|
|
|
typedef uint32 ProtocolVersion; /* FE/BE protocol version number */
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-04-18 00:26:02 +02:00
|
|
|
typedef ProtocolVersion MsgType;
|
1998-01-26 02:42:53 +01:00
|
|
|
|
1998-02-26 05:46:47 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
2003-04-18 00:26:02 +02:00
|
|
|
* Packet lengths are 4 bytes in network byte order.
|
|
|
|
*
|
|
|
|
* The initial length is omitted from the packet layouts appearing below.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1998-01-26 02:42:53 +01:00
|
|
|
|
2003-04-18 00:26:02 +02:00
|
|
|
typedef uint32 PacketLen;
|
|
|
|
|
2022-04-08 14:16:38 +02:00
|
|
|
extern PGDLLIMPORT bool Db_user_namespace;
|
1998-01-26 02:42:53 +01:00
|
|
|
|
2003-04-18 00:26:02 +02:00
|
|
|
/*
|
|
|
|
* In protocol 3.0 and later, the startup packet length is not fixed, but
|
|
|
|
* we set an arbitrary limit on it anyway. This is just to prevent simple
|
|
|
|
* denial-of-service attacks via sending enough data to run the server
|
|
|
|
* out of memory.
|
|
|
|
*/
|
|
|
|
#define MAX_STARTUP_PACKET_LENGTH 10000
|
|
|
|
|
|
|
|
|
|
|
|
/* These are the authentication request codes sent by the backend. */
|
1998-01-26 02:42:53 +01:00
|
|
|
|
2001-08-15 20:42:16 +02:00
|
|
|
#define AUTH_REQ_OK 0 /* User is authenticated */
|
2005-06-27 04:04:26 +02:00
|
|
|
#define AUTH_REQ_KRB4 1 /* Kerberos V4. Not supported any more. */
|
2014-01-15 17:24:01 +01:00
|
|
|
#define AUTH_REQ_KRB5 2 /* Kerberos V5. Not supported any more. */
|
1998-01-26 02:42:53 +01:00
|
|
|
#define AUTH_REQ_PASSWORD 3 /* Password */
|
2008-10-28 13:10:44 +01:00
|
|
|
#define AUTH_REQ_CRYPT 4 /* crypt password. Not supported any more. */
|
2001-08-15 20:42:16 +02:00
|
|
|
#define AUTH_REQ_MD5 5 /* md5 password */
|
2001-08-21 02:33:28 +02:00
|
|
|
#define AUTH_REQ_SCM_CREDS 6 /* transfer SCM credentials */
|
2007-07-10 15:14:22 +02:00
|
|
|
#define AUTH_REQ_GSS 7 /* GSSAPI without wrap() */
|
|
|
|
#define AUTH_REQ_GSS_CONT 8 /* Continue GSS exchanges */
|
2007-07-23 12:16:54 +02:00
|
|
|
#define AUTH_REQ_SSPI 9 /* SSPI negotiate without wrap() */
|
Improve the SASL authentication protocol.
This contains some protocol changes to SASL authentiation (which is new
in v10):
* For future-proofing, in the AuthenticationSASL message that begins SASL
authentication, provide a list of SASL mechanisms that the server
supports, for the client to choose from. Currently, it's always just
SCRAM-SHA-256.
* Add a separate authentication message type for the final server->client
SASL message, which the client doesn't need to respond to. This makes
it unambiguous whether the client is supposed to send a response or not.
The SASL mechanism should know that anyway, but better to be explicit.
Also, in the server, support clients that don't send an Initial Client
response in the first SASLInitialResponse message. The server is supposed
to first send an empty request in that case, to which the client will
respond with the data that usually comes in the Initial Client Response.
libpq uses the Initial Client Response field and doesn't need this, and I
would assume any other sensible implementation to use Initial Client
Response, too, but let's follow the SASL spec.
Improve the documentation on SASL authentication in protocol. Add a
section describing the SASL message flow, and some details on our
SCRAM-SHA-256 implementation.
Document the different kinds of PasswordMessages that the frontend sends
in different phases of SASL authentication, as well as GSS/SSPI
authentication as separate message formats. Even though they're all 'p'
messages, and the exact format depends on the context, describing them as
separate message formats makes the documentation more clear.
Reviewed by Michael Paquier and Álvaro Hernández Tortosa.
Discussion: https://www.postgresql.org/message-id/CAB7nPqS-aFg0iM3AQOJwKDv_0WkAedRjs1W2X8EixSz+sKBXCQ@mail.gmail.com
2017-04-13 18:34:16 +02:00
|
|
|
#define AUTH_REQ_SASL 10 /* Begin SASL authentication */
|
|
|
|
#define AUTH_REQ_SASL_CONT 11 /* Continue SASL authentication */
|
|
|
|
#define AUTH_REQ_SASL_FIN 12 /* Final SASL message */
|
1998-01-26 02:42:53 +01:00
|
|
|
|
|
|
|
typedef uint32 AuthRequest;
|
|
|
|
|
|
|
|
|
2003-04-18 00:26:02 +02:00
|
|
|
/*
|
|
|
|
* A client can also send a cancel-current-operation request to the postmaster.
|
1998-07-09 05:29:11 +02:00
|
|
|
* This is uglier than sending it directly to the client's backend, but it
|
|
|
|
* avoids depending on out-of-band communication facilities.
|
2003-04-18 00:26:02 +02:00
|
|
|
*
|
|
|
|
* The cancel request code must not match any protocol version number
|
1998-07-09 05:29:11 +02:00
|
|
|
* we're ever likely to use. This random choice should do.
|
|
|
|
*/
|
|
|
|
#define CANCEL_REQUEST_CODE PG_PROTOCOL(1234,5678)
|
|
|
|
|
|
|
|
typedef struct CancelRequestPacket
|
|
|
|
{
|
|
|
|
/* Note that each field is stored in network byte order! */
|
|
|
|
MsgType cancelRequestCode; /* code to identify a cancel request */
|
|
|
|
uint32 backendPID; /* PID of client's backend */
|
|
|
|
uint32 cancelAuthCode; /* secret key to authorize cancel */
|
|
|
|
} CancelRequestPacket;
|
|
|
|
|
1999-09-27 05:13:16 +02:00
|
|
|
|
|
|
|
/*
|
GSSAPI encryption support
On both the frontend and backend, prepare for GSSAPI encryption
support by moving common code for error handling into a separate file.
Fix a TODO for handling multiple status messages in the process.
Eliminate the OIDs, which have not been needed for some time.
Add frontend and backend encryption support functions. Keep the
context initiation for authentication-only separate on both the
frontend and backend in order to avoid concerns about changing the
requested flags to include encryption support.
In postmaster, pull GSSAPI authorization checking into a shared
function. Also share the initiator name between the encryption and
non-encryption codepaths.
For HBA, add "hostgssenc" and "hostnogssenc" entries that behave
similarly to their SSL counterparts. "hostgssenc" requires either
"gss", "trust", or "reject" for its authentication.
Similarly, add a "gssencmode" parameter to libpq. Supported values are
"disable", "require", and "prefer". Notably, negotiation will only be
attempted if credentials can be acquired. Move credential acquisition
into its own function to support this behavior.
Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring
if GSSAPI authentication was used, what principal was used, and if
encryption is being used on the connection.
Finally, add documentation for everything new, and update existing
documentation on connection security.
Thanks to Michael Paquier for the Windows fixes.
Author: Robbie Harwood, with changes to the read/write functions by me.
Reviewed in various forms and at different times by: Michael Paquier,
Andres Freund, David Steele.
Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
|
|
|
* A client can also start by sending a SSL or GSSAPI negotiation request to
|
|
|
|
* get a secure channel.
|
1999-09-27 05:13:16 +02:00
|
|
|
*/
|
|
|
|
#define NEGOTIATE_SSL_CODE PG_PROTOCOL(1234,5679)
|
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
|
|
|
#define NEGOTIATE_GSS_CODE PG_PROTOCOL(1234,5680)
|
1999-09-27 05:13:16 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
#endif /* PQCOMM_H */
|