2019-04-20 03:22:22 +02:00
|
|
|
# Sets up a KDC and then runs a variety of tests to make sure that the
|
|
|
|
# GSSAPI/Kerberos authentication and encryption are working properly,
|
|
|
|
# that the options in pg_hba.conf and pg_ident.conf are handled correctly,
|
|
|
|
# and that the server-side pg_stat_gssapi view reports what we expect to
|
|
|
|
# see for each test.
|
|
|
|
#
|
|
|
|
# Since this requires setting up a full KDC, it doesn't make much sense
|
|
|
|
# to have multiple test scripts (since they'd have to also create their
|
|
|
|
# own KDC and that could cause race conditions or other problems)- so
|
|
|
|
# just add whatever other tests are needed to here.
|
|
|
|
#
|
|
|
|
# See the README for additional information.
|
|
|
|
|
2018-03-05 20:42:11 +01:00
|
|
|
use strict;
|
|
|
|
use warnings;
|
|
|
|
use TestLib;
|
|
|
|
use PostgresNode;
|
|
|
|
use Test::More;
|
2020-12-02 20:41:53 +01:00
|
|
|
use Time::HiRes qw(usleep);
|
2018-03-05 20:42:11 +01:00
|
|
|
|
|
|
|
if ($ENV{with_gssapi} eq 'yes')
|
|
|
|
{
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
plan tests => 44;
|
2018-03-05 20:42:11 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
plan skip_all => 'GSSAPI/Kerberos not supported by this build';
|
|
|
|
}
|
|
|
|
|
|
|
|
my ($krb5_bin_dir, $krb5_sbin_dir);
|
|
|
|
|
|
|
|
if ($^O eq 'darwin')
|
|
|
|
{
|
2018-04-25 20:00:19 +02:00
|
|
|
$krb5_bin_dir = '/usr/local/opt/krb5/bin';
|
2018-03-05 20:42:11 +01:00
|
|
|
$krb5_sbin_dir = '/usr/local/opt/krb5/sbin';
|
|
|
|
}
|
|
|
|
elsif ($^O eq 'freebsd')
|
|
|
|
{
|
2018-04-25 20:00:19 +02:00
|
|
|
$krb5_bin_dir = '/usr/local/bin';
|
2018-03-05 20:42:11 +01:00
|
|
|
$krb5_sbin_dir = '/usr/local/sbin';
|
|
|
|
}
|
|
|
|
elsif ($^O eq 'linux')
|
|
|
|
{
|
|
|
|
$krb5_sbin_dir = '/usr/sbin';
|
|
|
|
}
|
|
|
|
|
2018-04-25 20:00:19 +02:00
|
|
|
my $krb5_config = 'krb5-config';
|
|
|
|
my $kinit = 'kinit';
|
|
|
|
my $kdb5_util = 'kdb5_util';
|
2018-03-05 20:42:11 +01:00
|
|
|
my $kadmin_local = 'kadmin.local';
|
2018-04-25 20:00:19 +02:00
|
|
|
my $krb5kdc = 'krb5kdc';
|
2018-03-05 20:42:11 +01:00
|
|
|
|
|
|
|
if ($krb5_bin_dir && -d $krb5_bin_dir)
|
|
|
|
{
|
|
|
|
$krb5_config = $krb5_bin_dir . '/' . $krb5_config;
|
2018-04-25 20:00:19 +02:00
|
|
|
$kinit = $krb5_bin_dir . '/' . $kinit;
|
2018-03-05 20:42:11 +01:00
|
|
|
}
|
|
|
|
if ($krb5_sbin_dir && -d $krb5_sbin_dir)
|
|
|
|
{
|
2018-04-25 20:00:19 +02:00
|
|
|
$kdb5_util = $krb5_sbin_dir . '/' . $kdb5_util;
|
2018-03-05 20:42:11 +01:00
|
|
|
$kadmin_local = $krb5_sbin_dir . '/' . $kadmin_local;
|
2018-04-25 20:00:19 +02:00
|
|
|
$krb5kdc = $krb5_sbin_dir . '/' . $krb5kdc;
|
2018-03-05 20:42:11 +01:00
|
|
|
}
|
|
|
|
|
2018-08-04 05:53:25 +02:00
|
|
|
my $host = 'auth-test-localhost.postgresql.example.com';
|
|
|
|
my $hostaddr = '127.0.0.1';
|
2019-04-20 03:22:22 +02:00
|
|
|
my $realm = 'EXAMPLE.COM';
|
2018-03-05 20:42:11 +01:00
|
|
|
|
2018-04-25 20:00:19 +02:00
|
|
|
my $krb5_conf = "${TestLib::tmp_check}/krb5.conf";
|
|
|
|
my $kdc_conf = "${TestLib::tmp_check}/kdc.conf";
|
2021-01-25 20:53:13 +01:00
|
|
|
my $krb5_cache = "${TestLib::tmp_check}/krb5cc";
|
2019-08-06 23:08:07 +02:00
|
|
|
my $krb5_log = "${TestLib::log_path}/krb5libs.log";
|
|
|
|
my $kdc_log = "${TestLib::log_path}/krb5kdc.log";
|
2019-08-04 19:07:12 +02:00
|
|
|
my $kdc_port = get_free_port();
|
2018-03-05 20:42:11 +01:00
|
|
|
my $kdc_datadir = "${TestLib::tmp_check}/krb5kdc";
|
|
|
|
my $kdc_pidfile = "${TestLib::tmp_check}/krb5kdc.pid";
|
2018-04-25 20:00:19 +02:00
|
|
|
my $keytab = "${TestLib::tmp_check}/krb5.keytab";
|
2018-03-05 20:42:11 +01:00
|
|
|
|
2020-12-02 20:41:53 +01:00
|
|
|
my $dbname = 'postgres';
|
|
|
|
my $username = 'test1';
|
|
|
|
my $application = '001_auth.pl';
|
|
|
|
|
2018-03-05 20:42:11 +01:00
|
|
|
note "setting up Kerberos";
|
|
|
|
|
|
|
|
my ($stdout, $krb5_version);
|
2018-04-25 20:00:19 +02:00
|
|
|
run_log [ $krb5_config, '--version' ], '>', \$stdout
|
|
|
|
or BAIL_OUT("could not execute krb5-config");
|
2018-03-05 20:42:11 +01:00
|
|
|
BAIL_OUT("Heimdal is not supported") if $stdout =~ m/heimdal/;
|
2018-04-25 20:00:19 +02:00
|
|
|
$stdout =~ m/Kerberos 5 release ([0-9]+\.[0-9]+)/
|
|
|
|
or BAIL_OUT("could not get Kerberos version");
|
2018-03-05 20:42:11 +01:00
|
|
|
$krb5_version = $1;
|
|
|
|
|
2018-04-25 20:00:19 +02:00
|
|
|
append_to_file(
|
|
|
|
$krb5_conf,
|
|
|
|
qq![logging]
|
2018-03-05 20:42:11 +01:00
|
|
|
default = FILE:$krb5_log
|
|
|
|
kdc = FILE:$kdc_log
|
|
|
|
|
|
|
|
[libdefaults]
|
|
|
|
default_realm = $realm
|
|
|
|
|
|
|
|
[realms]
|
|
|
|
$realm = {
|
2018-08-04 05:53:25 +02:00
|
|
|
kdc = $hostaddr:$kdc_port
|
2018-03-05 20:42:11 +01:00
|
|
|
}!);
|
|
|
|
|
2018-04-25 20:00:19 +02:00
|
|
|
append_to_file(
|
|
|
|
$kdc_conf,
|
|
|
|
qq![kdcdefaults]
|
2018-03-05 20:42:11 +01:00
|
|
|
!);
|
2018-04-25 20:00:19 +02:00
|
|
|
|
2018-03-05 20:42:11 +01:00
|
|
|
# For new-enough versions of krb5, use the _listen settings rather
|
|
|
|
# than the _ports settings so that we can bind to localhost only.
|
|
|
|
if ($krb5_version >= 1.15)
|
|
|
|
{
|
2018-04-25 20:00:19 +02:00
|
|
|
append_to_file(
|
|
|
|
$kdc_conf,
|
2018-08-04 05:53:25 +02:00
|
|
|
qq!kdc_listen = $hostaddr:$kdc_port
|
|
|
|
kdc_tcp_listen = $hostaddr:$kdc_port
|
2018-03-05 20:42:11 +01:00
|
|
|
!);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2018-04-25 20:00:19 +02:00
|
|
|
append_to_file(
|
|
|
|
$kdc_conf,
|
|
|
|
qq!kdc_ports = $kdc_port
|
2018-03-05 20:42:11 +01:00
|
|
|
kdc_tcp_ports = $kdc_port
|
|
|
|
!);
|
|
|
|
}
|
2018-04-25 20:00:19 +02:00
|
|
|
append_to_file(
|
|
|
|
$kdc_conf,
|
|
|
|
qq!
|
2018-03-05 20:42:11 +01:00
|
|
|
[realms]
|
|
|
|
$realm = {
|
|
|
|
database_name = $kdc_datadir/principal
|
|
|
|
admin_keytab = FILE:$kdc_datadir/kadm5.keytab
|
|
|
|
acl_file = $kdc_datadir/kadm5.acl
|
|
|
|
key_stash_file = $kdc_datadir/_k5.$realm
|
|
|
|
}!);
|
|
|
|
|
|
|
|
mkdir $kdc_datadir or die;
|
|
|
|
|
2021-01-25 20:53:13 +01:00
|
|
|
# Ensure that we use test's config and cache files, not global ones.
|
2018-04-25 20:00:19 +02:00
|
|
|
$ENV{'KRB5_CONFIG'} = $krb5_conf;
|
2018-03-05 20:42:11 +01:00
|
|
|
$ENV{'KRB5_KDC_PROFILE'} = $kdc_conf;
|
2021-01-25 20:53:13 +01:00
|
|
|
$ENV{'KRB5CCNAME'} = $krb5_cache;
|
2018-03-05 20:42:11 +01:00
|
|
|
|
2018-08-04 05:53:25 +02:00
|
|
|
my $service_principal = "$ENV{with_krb_srvnam}/$host";
|
2018-03-05 20:42:11 +01:00
|
|
|
|
|
|
|
system_or_bail $kdb5_util, 'create', '-s', '-P', 'secret0';
|
|
|
|
|
|
|
|
my $test1_password = 'secret1';
|
|
|
|
system_or_bail $kadmin_local, '-q', "addprinc -pw $test1_password test1";
|
|
|
|
|
|
|
|
system_or_bail $kadmin_local, '-q', "addprinc -randkey $service_principal";
|
|
|
|
system_or_bail $kadmin_local, '-q', "ktadd -k $keytab $service_principal";
|
|
|
|
|
|
|
|
system_or_bail $krb5kdc, '-P', $kdc_pidfile;
|
|
|
|
|
|
|
|
END
|
|
|
|
{
|
2018-04-25 20:00:19 +02:00
|
|
|
kill 'INT', `cat $kdc_pidfile` if -f $kdc_pidfile;
|
2018-03-05 20:42:11 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
note "setting up PostgreSQL instance";
|
|
|
|
|
|
|
|
my $node = get_new_node('node');
|
|
|
|
$node->init;
|
2020-12-25 03:37:46 +01:00
|
|
|
$node->append_conf(
|
|
|
|
'postgresql.conf', qq{
|
|
|
|
listen_addresses = '$hostaddr'
|
|
|
|
krb_server_keyfile = '$keytab'
|
|
|
|
log_connections = on
|
|
|
|
lc_messages = 'C'
|
|
|
|
});
|
2018-03-05 20:42:11 +01:00
|
|
|
$node->start;
|
|
|
|
|
|
|
|
$node->safe_psql('postgres', 'CREATE USER test1;');
|
|
|
|
|
|
|
|
note "running tests";
|
|
|
|
|
2020-01-11 23:14:08 +01:00
|
|
|
# Test connection success or failure, and if success, that query returns true.
|
2018-03-05 20:42:11 +01:00
|
|
|
sub test_access
|
|
|
|
{
|
2021-04-05 03:13:57 +02:00
|
|
|
my ($node, $role, $query, $expected_res, $gssencmode, $test_name,
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
@expect_log_msgs)
|
2021-04-05 03:13:57 +02:00
|
|
|
= @_;
|
2018-03-05 20:42:11 +01:00
|
|
|
|
|
|
|
# need to connect over TCP/IP for Kerberos
|
2021-04-05 03:13:57 +02:00
|
|
|
my $connstr = $node->connstr('postgres')
|
|
|
|
. " user=$role host=$host hostaddr=$hostaddr $gssencmode";
|
|
|
|
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
my %params = (
|
|
|
|
sql => $query,
|
|
|
|
);
|
|
|
|
|
|
|
|
if (@expect_log_msgs)
|
|
|
|
{
|
|
|
|
# Match every message literally.
|
|
|
|
my @regexes = map { qr/\Q$_\E/ } @expect_log_msgs;
|
|
|
|
|
|
|
|
$params{log_like} = \@regexes;
|
|
|
|
}
|
|
|
|
|
2021-04-05 03:13:57 +02:00
|
|
|
if ($expected_res eq 0)
|
2019-04-20 03:22:22 +02:00
|
|
|
{
|
2021-04-05 03:13:57 +02:00
|
|
|
# The result is assumed to match "true", or "t", here.
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
$params{expected_stdout} = qr/^t$/;
|
|
|
|
|
|
|
|
$node->connect_ok($connstr, $test_name, %params);
|
2019-04-20 03:22:22 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
$node->connect_fails($connstr, $test_name, %params);
|
2019-04-20 03:22:22 +02:00
|
|
|
}
|
2018-03-05 20:42:11 +01:00
|
|
|
}
|
|
|
|
|
2020-01-11 23:14:08 +01:00
|
|
|
# As above, but test for an arbitrary query result.
|
|
|
|
sub test_query
|
|
|
|
{
|
|
|
|
my ($node, $role, $query, $expected, $gssencmode, $test_name) = @_;
|
|
|
|
|
|
|
|
# need to connect over TCP/IP for Kerberos
|
2021-04-05 03:13:57 +02:00
|
|
|
my $connstr = $node->connstr('postgres')
|
|
|
|
. " user=$role host=$host hostaddr=$hostaddr $gssencmode";
|
|
|
|
|
2021-04-06 06:23:57 +02:00
|
|
|
$node->connect_ok(
|
|
|
|
$connstr, $test_name,
|
|
|
|
sql => $query,
|
|
|
|
expected_stdout => $expected);
|
2020-01-11 23:14:08 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-03-05 20:42:11 +01:00
|
|
|
unlink($node->data_dir . '/pg_hba.conf');
|
2018-08-04 05:53:25 +02:00
|
|
|
$node->append_conf('pg_hba.conf',
|
|
|
|
qq{host all all $hostaddr/32 gss map=mymap});
|
2018-03-05 20:42:11 +01:00
|
|
|
$node->restart;
|
|
|
|
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
test_access($node, 'test1', 'SELECT true', 2, '', 'fails without ticket');
|
2018-03-05 20:42:11 +01:00
|
|
|
|
|
|
|
run_log [ $kinit, 'test1' ], \$test1_password or BAIL_OUT($?);
|
|
|
|
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
test_access(
|
|
|
|
$node,
|
|
|
|
'test1',
|
|
|
|
'SELECT true',
|
|
|
|
2,
|
|
|
|
'',
|
|
|
|
'fails without mapping',
|
|
|
|
"connection authenticated: identity=\"test1\@$realm\" method=gss",
|
|
|
|
"no match in usermap \"mymap\" for user \"test1\"");
|
2018-03-05 20:42:11 +01:00
|
|
|
|
|
|
|
$node->append_conf('pg_ident.conf', qq{mymap /^(.*)\@$realm\$ \\1});
|
|
|
|
$node->restart;
|
|
|
|
|
2019-04-20 03:22:22 +02:00
|
|
|
test_access(
|
|
|
|
$node,
|
|
|
|
'test1',
|
|
|
|
'SELECT gss_authenticated AND encrypted from pg_stat_gssapi where pid = pg_backend_pid();',
|
|
|
|
0,
|
|
|
|
'',
|
2020-12-02 20:41:53 +01:00
|
|
|
'succeeds with mapping with default gssencmode and host hba',
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
"connection authenticated: identity=\"test1\@$realm\" method=gss",
|
2020-12-02 20:41:53 +01:00
|
|
|
"connection authorized: user=$username database=$dbname application_name=$application GSS (authenticated=yes, encrypted=yes, principal=test1\@$realm)"
|
|
|
|
);
|
|
|
|
|
2019-04-20 03:22:22 +02:00
|
|
|
test_access(
|
|
|
|
$node,
|
2020-12-02 20:41:53 +01:00
|
|
|
'test1',
|
2019-04-20 03:22:22 +02:00
|
|
|
'SELECT gss_authenticated AND encrypted from pg_stat_gssapi where pid = pg_backend_pid();',
|
|
|
|
0,
|
2020-12-02 20:41:53 +01:00
|
|
|
'gssencmode=prefer',
|
|
|
|
'succeeds with GSS-encrypted access preferred with host hba',
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
"connection authenticated: identity=\"test1\@$realm\" method=gss",
|
2020-12-02 20:41:53 +01:00
|
|
|
"connection authorized: user=$username database=$dbname application_name=$application GSS (authenticated=yes, encrypted=yes, principal=test1\@$realm)"
|
|
|
|
);
|
2019-04-20 03:22:22 +02:00
|
|
|
test_access(
|
|
|
|
$node,
|
2020-12-02 20:41:53 +01:00
|
|
|
'test1',
|
2019-04-20 03:22:22 +02:00
|
|
|
'SELECT gss_authenticated AND encrypted from pg_stat_gssapi where pid = pg_backend_pid();',
|
|
|
|
0,
|
2020-12-02 20:41:53 +01:00
|
|
|
'gssencmode=require',
|
|
|
|
'succeeds with GSS-encrypted access required with host hba',
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
"connection authenticated: identity=\"test1\@$realm\" method=gss",
|
2020-12-02 20:41:53 +01:00
|
|
|
"connection authorized: user=$username database=$dbname application_name=$application GSS (authenticated=yes, encrypted=yes, principal=test1\@$realm)"
|
|
|
|
);
|
2019-04-20 03:22:22 +02:00
|
|
|
|
2020-01-11 23:14:08 +01:00
|
|
|
# Test that we can transport a reasonable amount of data.
|
|
|
|
test_query(
|
|
|
|
$node,
|
2020-12-02 20:41:53 +01:00
|
|
|
'test1',
|
2020-01-11 23:14:08 +01:00
|
|
|
'SELECT * FROM generate_series(1, 100000);',
|
|
|
|
qr/^1\n.*\n1024\n.*\n9999\n.*\n100000$/s,
|
2020-12-02 20:41:53 +01:00
|
|
|
'gssencmode=require',
|
|
|
|
'receiving 100K lines works');
|
2020-01-11 23:14:08 +01:00
|
|
|
|
|
|
|
test_query(
|
|
|
|
$node,
|
2020-12-02 20:41:53 +01:00
|
|
|
'test1',
|
2020-01-11 23:14:08 +01:00
|
|
|
"CREATE TABLE mytab (f1 int primary key);\n"
|
|
|
|
. "COPY mytab FROM STDIN;\n"
|
|
|
|
. join("\n", (1 .. 100000))
|
|
|
|
. "\n\\.\n"
|
|
|
|
. "SELECT COUNT(*) FROM mytab;",
|
|
|
|
qr/^100000$/s,
|
2020-12-02 20:41:53 +01:00
|
|
|
'gssencmode=require',
|
|
|
|
'sending 100K lines works');
|
2020-01-11 23:14:08 +01:00
|
|
|
|
2019-04-20 03:22:22 +02:00
|
|
|
unlink($node->data_dir . '/pg_hba.conf');
|
|
|
|
$node->append_conf('pg_hba.conf',
|
|
|
|
qq{hostgssenc all all $hostaddr/32 gss map=mymap});
|
|
|
|
$node->restart;
|
|
|
|
|
|
|
|
test_access(
|
|
|
|
$node,
|
2020-12-02 20:41:53 +01:00
|
|
|
'test1',
|
2019-04-20 03:22:22 +02:00
|
|
|
'SELECT gss_authenticated AND encrypted from pg_stat_gssapi where pid = pg_backend_pid();',
|
|
|
|
0,
|
2020-12-02 20:41:53 +01:00
|
|
|
'gssencmode=prefer',
|
|
|
|
'succeeds with GSS-encrypted access preferred and hostgssenc hba',
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
"connection authenticated: identity=\"test1\@$realm\" method=gss",
|
2020-12-02 20:41:53 +01:00
|
|
|
"connection authorized: user=$username database=$dbname application_name=$application GSS (authenticated=yes, encrypted=yes, principal=test1\@$realm)"
|
|
|
|
);
|
2019-04-20 03:22:22 +02:00
|
|
|
test_access(
|
|
|
|
$node,
|
2020-12-02 20:41:53 +01:00
|
|
|
'test1',
|
2019-04-20 03:22:22 +02:00
|
|
|
'SELECT gss_authenticated AND encrypted from pg_stat_gssapi where pid = pg_backend_pid();',
|
|
|
|
0,
|
2020-12-02 20:41:53 +01:00
|
|
|
'gssencmode=require',
|
|
|
|
'succeeds with GSS-encrypted access required and hostgssenc hba',
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
"connection authenticated: identity=\"test1\@$realm\" method=gss",
|
2020-12-02 20:41:53 +01:00
|
|
|
"connection authorized: user=$username database=$dbname application_name=$application GSS (authenticated=yes, encrypted=yes, principal=test1\@$realm)"
|
|
|
|
);
|
|
|
|
test_access($node, 'test1', 'SELECT true', 2, 'gssencmode=disable',
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
'fails with GSS encryption disabled and hostgssenc hba');
|
2019-04-20 03:22:22 +02:00
|
|
|
|
|
|
|
unlink($node->data_dir . '/pg_hba.conf');
|
|
|
|
$node->append_conf('pg_hba.conf',
|
|
|
|
qq{hostnogssenc all all $hostaddr/32 gss map=mymap});
|
|
|
|
$node->restart;
|
|
|
|
|
|
|
|
test_access(
|
|
|
|
$node,
|
2020-12-02 20:41:53 +01:00
|
|
|
'test1',
|
2019-04-20 03:22:22 +02:00
|
|
|
'SELECT gss_authenticated and not encrypted from pg_stat_gssapi where pid = pg_backend_pid();',
|
|
|
|
0,
|
2020-12-02 20:41:53 +01:00
|
|
|
'gssencmode=prefer',
|
|
|
|
'succeeds with GSS-encrypted access preferred and hostnogssenc hba, but no encryption',
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
"connection authenticated: identity=\"test1\@$realm\" method=gss",
|
2020-12-02 20:41:53 +01:00
|
|
|
"connection authorized: user=$username database=$dbname application_name=$application GSS (authenticated=yes, encrypted=no, principal=test1\@$realm)"
|
2019-04-20 03:22:22 +02:00
|
|
|
);
|
2020-12-02 20:41:53 +01:00
|
|
|
test_access($node, 'test1', 'SELECT true', 2, 'gssencmode=require',
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
'fails with GSS-encrypted access required and hostnogssenc hba');
|
2019-04-20 03:22:22 +02:00
|
|
|
test_access(
|
|
|
|
$node,
|
2020-12-02 20:41:53 +01:00
|
|
|
'test1',
|
2019-04-20 03:22:22 +02:00
|
|
|
'SELECT gss_authenticated and not encrypted from pg_stat_gssapi where pid = pg_backend_pid();',
|
|
|
|
0,
|
2020-12-02 20:41:53 +01:00
|
|
|
'gssencmode=disable',
|
|
|
|
'succeeds with GSS encryption disabled and hostnogssenc hba',
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
"connection authenticated: identity=\"test1\@$realm\" method=gss",
|
2020-12-02 20:41:53 +01:00
|
|
|
"connection authorized: user=$username database=$dbname application_name=$application GSS (authenticated=yes, encrypted=no, principal=test1\@$realm)"
|
|
|
|
);
|
2018-03-05 20:42:11 +01:00
|
|
|
|
|
|
|
truncate($node->data_dir . '/pg_ident.conf', 0);
|
|
|
|
unlink($node->data_dir . '/pg_hba.conf');
|
2018-04-25 20:00:19 +02:00
|
|
|
$node->append_conf('pg_hba.conf',
|
2018-08-04 05:53:25 +02:00
|
|
|
qq{host all all $hostaddr/32 gss include_realm=0});
|
2018-03-05 20:42:11 +01:00
|
|
|
$node->restart;
|
|
|
|
|
2019-04-20 03:22:22 +02:00
|
|
|
test_access(
|
|
|
|
$node,
|
|
|
|
'test1',
|
|
|
|
'SELECT gss_authenticated AND encrypted from pg_stat_gssapi where pid = pg_backend_pid();',
|
|
|
|
0,
|
|
|
|
'',
|
2020-12-02 20:41:53 +01:00
|
|
|
'succeeds with include_realm=0 and defaults',
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
"connection authenticated: identity=\"test1\@$realm\" method=gss",
|
2020-12-02 20:41:53 +01:00
|
|
|
"connection authorized: user=$username database=$dbname application_name=$application GSS (authenticated=yes, encrypted=yes, principal=test1\@$realm)"
|
|
|
|
);
|
Add some information about authenticated identity via log_connections
The "authenticated identity" is the string used by an authentication
method to identify a particular user. In many common cases, this is the
same as the PostgreSQL username, but for some third-party authentication
methods, the identifier in use may be shortened or otherwise translated
(e.g. through pg_ident user mappings) before the server stores it.
To help administrators see who has actually interacted with the system,
this commit adds the capability to store the original identity when
authentication succeeds within the backend's Port, and generates a log
entry when log_connections is enabled. The log entries generated look
something like this (where a local user named "foouser" is connecting to
the database as the database user called "admin"):
LOG: connection received: host=[local]
LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)
LOG: connection authorized: user=admin database=postgres application_name=psql
Port->authn_id is set according to the authentication method:
bsd: the PostgreSQL username (aka the local username)
cert: the client's Subject DN
gss: the user principal
ident: the remote username
ldap: the final bind DN
pam: the PostgreSQL username (aka PAM username)
password (and all pw-challenge methods): the PostgreSQL username
peer: the peer's pw_name
radius: the PostgreSQL username (aka the RADIUS username)
sspi: either the down-level (SAM-compatible) logon name, if
compat_realm=1, or the User Principal Name if compat_realm=0
The trust auth method does not set an authenticated identity. Neither
does clientcert=verify-full.
Port->authn_id could be used for other purposes, like a superuser-only
extra column in pg_stat_activity, but this is left as future work.
PostgresNode::connect_{ok,fails}() have been modified to let tests check
the backend log files for required or prohibited patterns, using the
new log_like and log_unlike parameters. This uses a method based on a
truncation of the existing server log file, like issues_sql_like().
Tests are added to the ldap, kerberos, authentication and SSL test
suites.
Author: Jacob Champion
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com
2021-04-07 03:16:39 +02:00
|
|
|
|
|
|
|
# Reset pg_hba.conf, and cause a usermap failure with an authentication
|
|
|
|
# that has passed.
|
|
|
|
unlink($node->data_dir . '/pg_hba.conf');
|
|
|
|
$node->append_conf('pg_hba.conf',
|
|
|
|
qq{host all all $hostaddr/32 gss include_realm=0 krb_realm=EXAMPLE.ORG});
|
|
|
|
$node->restart;
|
|
|
|
|
|
|
|
test_access(
|
|
|
|
$node,
|
|
|
|
'test1',
|
|
|
|
'SELECT true',
|
|
|
|
2,
|
|
|
|
'',
|
|
|
|
'fails with wrong krb_realm, but still authenticates',
|
|
|
|
"connection authenticated: identity=\"test1\@$realm\" method=gss");
|