mirror of
https://git.postgresql.org/git/postgresql.git
synced 2026-02-14 18:37:03 +08:00
b69aba7457
The existing cryptohash facility was causing problems in some code paths related to MD5 (frontend and backend) that relied on the fact that the only type of error that could happen would be an OOM, as the MD5 implementation used in PostgreSQL ~13 (the in-core implementation is used when compiling with or without OpenSSL in those older versions), could fail only under this circumstance. The new cryptohash facilities can fail for reasons other than OOMs, like attempting MD5 when FIPS is enabled (upstream OpenSSL allows that up to 1.0.2, Fedora and Photon patch OpenSSL 1.1.1 to allow that), so this would cause incorrect reports to show up. This commit extends the cryptohash APIs so as callers of those routines can fetch more context when an error happens, by using a new routine called pg_cryptohash_error(). The error states are stored within each implementation's internal context data, so as it is possible to extend the logic depending on what's suited for an implementation. The default implementation requires few error states, but OpenSSL could report various issues depending on its internal state so more is needed in cryptohash_openssl.c, and the code is shaped so as we are always able to grab the necessary information. The core code is changed to adapt to the new error routine, painting more "const" across the call stack where the static errors are stored, particularly in authentication code paths on variables that provide log details. This way, any future changes would warn if attempting to free these strings. The MD5 authentication code was also a bit blurry about the handling of "logdetail" (LOG sent to the postmaster), so improve the comments related that, while on it. The origin of the problem is 87ae969, that introduced the centralized cryptohash facility. Extra changes are done for pgcrypto in v14 for the non-OpenSSL code path to cope with the improvements done by this commit. Reported-by: Michael Mühlbeyer Author: Michael Paquier Reviewed-by: Tom Lane Discussion: https://postgr.es/m/89B7F072-5BBE-4C92-903E-D83E865D9367@trivadis.com Backpatch-through: 14
48 lines
1.5 KiB
C
48 lines
1.5 KiB
C
/*-------------------------------------------------------------------------
|
|
*
|
|
* crypt.h
|
|
* Interface to libpq/crypt.c
|
|
*
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
*
|
|
* src/include/libpq/crypt.h
|
|
*
|
|
*-------------------------------------------------------------------------
|
|
*/
|
|
#ifndef PG_CRYPT_H
|
|
#define PG_CRYPT_H
|
|
|
|
#include "datatype/timestamp.h"
|
|
|
|
/*
|
|
* Types of password hashes or secrets.
|
|
*
|
|
* Plaintext passwords can be passed in by the user, in a CREATE/ALTER USER
|
|
* command. They will be encrypted to MD5 or SCRAM-SHA-256 format, before
|
|
* storing on-disk, so only MD5 and SCRAM-SHA-256 passwords should appear
|
|
* in pg_authid.rolpassword. They are also the allowed values for the
|
|
* password_encryption GUC.
|
|
*/
|
|
typedef enum PasswordType
|
|
{
|
|
PASSWORD_TYPE_PLAINTEXT = 0,
|
|
PASSWORD_TYPE_MD5,
|
|
PASSWORD_TYPE_SCRAM_SHA_256
|
|
} PasswordType;
|
|
|
|
extern PasswordType get_password_type(const char *shadow_pass);
|
|
extern char *encrypt_password(PasswordType target_type, const char *role,
|
|
const char *password);
|
|
|
|
extern char *get_role_password(const char *role, const char **logdetail);
|
|
|
|
extern int md5_crypt_verify(const char *role, const char *shadow_pass,
|
|
const char *client_pass, const char *md5_salt,
|
|
int md5_salt_len, const char **logdetail);
|
|
extern int plain_crypt_verify(const char *role, const char *shadow_pass,
|
|
const char *client_pass,
|
|
const char **logdetail);
|
|
|
|
#endif
|