allow specifying direct role membership in pg_hba.conf
Hi hackers,
I've attached a small patch that allows specifying only direct members
of a group in pg_hba.conf. The "+" prefix offered today matches both
direct and indirect role members, which may complicate some role
setups. For example, if you have one set of roles that are members of
the "pam" role and another set that are members of the "scram-sha-256"
role, granting membership in a PAM role to a SCRAM role might
inadvertently modify the desired authentication method for the
grantee. If only direct membership is considered, no such inadvertent
authentication method change would occur.
I chose "&" as a new group name prefix for this purpose. This choice
seemed as good as any, but I'm open to changing it if anyone has
suggestions. For determining direct role membership, I added a new
function in acl.c that matches other related functions. I added a new
role cache type since it seemed to fit in reasonably well, but it seems
unlikely that there is any real performance benefit versus simply
open-coding the syscache lookup.
I didn't see any existing authentication tests for groups at first
glance. If folks are interested in this functionality, I can work on
adding some tests for this stuff.
Nathan
Attachments:
v1-0001-Allow-specifying-direct-role-membership-in-pg_hba.patchapplication/octet-stream; name=v1-0001-Allow-specifying-direct-role-membership-in-pg_hba.patchDownload
From edcab4bef4d3384763a0a45b4453cbce327f50f1 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <bossartn@amazon.com>
Date: Thu, 13 May 2021 23:04:34 +0000
Subject: [PATCH v1 1/1] Allow specifying direct role membership in
pg_hba.conf.
---
doc/src/sgml/client-auth.sgml | 29 +++++++++++++++++-----------
src/backend/libpq/hba.c | 22 ++++++++++++++-------
src/backend/libpq/pg_hba.conf.sample | 10 ++++++----
src/backend/utils/adt/acl.c | 37 ++++++++++++++++++++++++++++++++----
src/include/utils/acl.h | 1 +
5 files changed, 73 insertions(+), 26 deletions(-)
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index 951af49e9a..3639903550 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -249,18 +249,21 @@ hostnogssenc <replaceable>database</replaceable> <replaceable>user</replaceabl
Specifies which database user name(s) this record
matches. The value <literal>all</literal> specifies that it
matches all users. Otherwise, this is either the name of a specific
- database user, or a group name preceded by <literal>+</literal>.
- (Recall that there is no real distinction between users and groups
- in <productname>PostgreSQL</productname>; a <literal>+</literal> mark really means
- <quote>match any of the roles that are directly or indirectly members
- of this role</quote>, while a name without a <literal>+</literal> mark matches
- only that specific role.) For this purpose, a superuser is only
+ database user, or a group name preceded by <literal>+</literal> or
+ <literal>&</literal>. Group names preceded by <literal>+</literal> match
+ roles that are directly or indirectly members of this role, and group
+ names preceded by <literal>&</literal> only match roles that are directly
+ members of this role. (Recall that there is no real distinction between
+ users and groups in <productname>PostgreSQL</productname>; a
+ <literal>+</literal> or <literal>&</literal> mark really means
+ <quote>match any of the roles that are members of this role</quote>,
+ while a name without a <literal>+</literal> or <literal>&</literal> mark
+ matches only that specific role.) For this purpose, a superuser is only
considered to be a member of a role if they are explicitly a member
- of the role, directly or indirectly, and not just by virtue of
- being a superuser.
- Multiple user names can be supplied by separating them with commas.
- A separate file containing user names can be specified by preceding the
- file name with <literal>@</literal>.
+ of the role and not just by virtue of being a superuser. Multiple user
+ names can be supplied by separating them with commas. A separate file
+ containing user names can be specified by preceding the file name with
+ <literal>@</literal>.
</para>
</listitem>
</varlistentry>
@@ -800,6 +803,10 @@ local all +support md5
# The last two lines above can be combined into a single line:
local all @admins,+support md5
+# Group names can also be specified using "&" to indicate that only direct
+# membership should be considered
+local all &support md5
+
# The database column can also use lists and file names:
local db1,db2,@demodbs all md5
</programlisting>
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 60767f2957..5dd0e6ad39 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -581,7 +581,7 @@ tokenize_file(const char *filename, FILE *file, List **tok_lines, int elevel)
* We check to see if it is a member of the specified role name.
*/
static bool
-is_member(Oid userid, const char *role)
+is_member(Oid userid, const char *role, bool only_direct)
{
Oid roleid;
@@ -594,11 +594,14 @@ is_member(Oid userid, const char *role)
return false; /* if target role not exist, say "no" */
/*
- * See if user is directly or indirectly a member of role. For this
- * purpose, a superuser is not considered to be automatically a member of
- * the role, so group auth only applies to explicit membership.
+ * See if user is a member of role. For this purpose, a superuser is not
+ * considered to be automatically a member of the role, so group auth only
+ * applies to explicit membership.
*/
- return is_member_of_role_nosuper(userid, roleid);
+ if (only_direct)
+ return is_direct_member_of_role_nosuper(userid, roleid);
+ else
+ return is_member_of_role_nosuper(userid, roleid);
}
/*
@@ -615,7 +618,12 @@ check_role(const char *role, Oid roleid, List *tokens)
tok = lfirst(cell);
if (!tok->quoted && tok->string[0] == '+')
{
- if (is_member(roleid, tok->string + 1))
+ if (is_member(roleid, tok->string + 1, false))
+ return true;
+ }
+ else if (!tok->quoted && tok->string[0] == '&')
+ {
+ if (is_member(roleid, tok->string + 1, true))
return true;
}
else if (token_matches(tok, role) ||
@@ -656,7 +664,7 @@ check_db(const char *dbname, const char *role, Oid roleid, List *tokens)
else if (token_is_keyword(tok, "samegroup") ||
token_is_keyword(tok, "samerole"))
{
- if (is_member(roleid, dbname))
+ if (is_member(roleid, dbname, false))
return true;
}
else if (token_is_keyword(tok, "replication"))
diff --git a/src/backend/libpq/pg_hba.conf.sample b/src/backend/libpq/pg_hba.conf.sample
index 5f3f63eb0c..8aef6ae742 100644
--- a/src/backend/libpq/pg_hba.conf.sample
+++ b/src/backend/libpq/pg_hba.conf.sample
@@ -31,10 +31,12 @@
# keyword does not match "replication". Access to replication
# must be enabled in a separate record (see example below).
#
-# USER can be "all", a user name, a group name prefixed with "+", or a
-# comma-separated list thereof. In both the DATABASE and USER fields
-# you can also write a file name prefixed with "@" to include names
-# from a separate file.
+# USER can be "all", a user name, a group name prefixed with "+" or
+# "&", or a comma-separated list thereof. Group names prefixed with
+# "+" match both direct and indirect members while group names
+# prefixed with "&" only match direct members. In both the DATABASE
+# and USER fields you can also write a file name prefixed with "@" to
+# include names from a separate file.
#
# ADDRESS specifies the set of hosts the record matches. It can be a
# host name, or it is made up of an IP address and a CIDR mask that is
diff --git a/src/backend/utils/adt/acl.c b/src/backend/utils/adt/acl.c
index 67f8b29434..0096f66aeb 100644
--- a/src/backend/utils/adt/acl.c
+++ b/src/backend/utils/adt/acl.c
@@ -65,10 +65,11 @@ typedef struct
enum RoleRecurseType
{
ROLERECURSE_PRIVS = 0, /* recurse if rolinherit */
- ROLERECURSE_MEMBERS = 1 /* recurse unconditionally */
+ ROLERECURSE_MEMBERS = 1, /* recurse unconditionally */
+ ROLERECURSE_DIRECT = 2 /* do not recurse */
};
-static Oid cached_role[] = {InvalidOid, InvalidOid};
-static List *cached_roles[] = {NIL, NIL};
+static Oid cached_role[] = {InvalidOid, InvalidOid, InvalidOid};
+static List *cached_roles[] = {NIL, NIL, NIL};
static uint32 cached_db_hash;
@@ -4687,6 +4688,7 @@ RoleMembershipCacheCallback(Datum arg, int cacheid, uint32 hashvalue)
/* Force membership caches to be recomputed on next use */
cached_role[ROLERECURSE_PRIVS] = InvalidOid;
cached_role[ROLERECURSE_MEMBERS] = InvalidOid;
+ cached_role[ROLERECURSE_DIRECT] = InvalidOid;
}
@@ -4711,7 +4713,8 @@ has_rolinherit(Oid roleid)
* Get a list of roles that the specified roleid is a member of
*
* Type ROLERECURSE_PRIVS recurses only through roles that have rolinherit
- * set, while ROLERECURSE_MEMBERS recurses through all roles. This sets
+ * set, ROLERECURSE_MEMBERS recurses through all roles, and ROLERECURSE_DIRECT
+ * only retrieves roles that roleid has direct membership in. This sets
* *is_admin==true if and only if role "roleid" has an ADMIN OPTION membership
* in role "admin_of".
*
@@ -4809,6 +4812,10 @@ roles_is_member_of(Oid roleid, enum RoleRecurseType type,
if (memberid == dba && OidIsValid(dba))
roles_list = list_append_unique_oid(roles_list,
ROLE_PG_DATABASE_OWNER);
+
+ /* if we are only interested in direct membership, we're done */
+ if (type == ROLERECURSE_DIRECT)
+ break;
}
/*
@@ -4899,6 +4906,28 @@ check_is_member_of_role(Oid member, Oid role)
GetUserNameFromId(role, false))));
}
+/*
+ * Is member a direct member of role, not considering superuserness?
+ *
+ * This is identical to is_member_of_role_nosuper except we do not check for
+ * indirect membership in the target role.
+ */
+bool
+is_direct_member_of_role_nosuper(Oid member, Oid role)
+{
+ /* Fast path for simple case */
+ if (member == role)
+ return true;
+
+ /*
+ * Find all the roles that member is a member of, but do not recurse, then
+ * see if target role is any one of them.
+ */
+ return list_member_oid(roles_is_member_of(member, ROLERECURSE_DIRECT,
+ InvalidOid, NULL),
+ role);
+}
+
/*
* Is member a member of role, not considering superuserness?
*
diff --git a/src/include/utils/acl.h b/src/include/utils/acl.h
index af771c901d..22ad4bb58c 100644
--- a/src/include/utils/acl.h
+++ b/src/include/utils/acl.h
@@ -207,6 +207,7 @@ extern int aclmembers(const Acl *acl, Oid **roleids);
extern bool has_privs_of_role(Oid member, Oid role);
extern bool is_member_of_role(Oid member, Oid role);
+extern bool is_direct_member_of_role_nosuper(Oid member, Oid role);
extern bool is_member_of_role_nosuper(Oid member, Oid role);
extern bool is_admin_of_role(Oid member, Oid role);
extern void check_is_member_of_role(Oid member, Oid role);
--
2.16.6
On 5/13/21 7:38 PM, Bossart, Nathan wrote:
Hi hackers,
I've attached a small patch that allows specifying only direct members
of a group in pg_hba.conf. The "+" prefix offered today matches both
direct and indirect role members, which may complicate some role
setups. For example, if you have one set of roles that are members of
the "pam" role and another set that are members of the "scram-sha-256"
role, granting membership in a PAM role to a SCRAM role might
inadvertently modify the desired authentication method for the
grantee. If only direct membership is considered, no such inadvertent
authentication method change would occur.I chose "&" as a new group name prefix for this purpose. This choice
seemed as good as any, but I'm open to changing it if anyone has
suggestions. For determining direct role membership, I added a new
function in acl.c that matches other related functions. I added a new
role cache type since it seemed to fit in reasonably well, but it seems
unlikely that there is any real performance benefit versus simply
open-coding the syscache lookup.I didn't see any existing authentication tests for groups at first
glance. If folks are interested in this functionality, I can work on
adding some tests for this stuff.
Do we really want to be creating two classes of role membership?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
On 5/13/21 7:38 PM, Bossart, Nathan wrote:
I've attached a small patch that allows specifying only direct members
of a group in pg_hba.conf.
Do we really want to be creating two classes of role membership?
Yeah, this seems to be going against the clear meaning of the
SQL spec. I realize you can argue that pg_hba.conf doesn't have
to follow the spec, but it doesn't seem like a terribly good idea
to interpret role membership differently in different places.
regards, tom lane
On 05/13/21 19:38, Bossart, Nathan wrote:
I chose "&" as a new group name prefix for this purpose. This choice
If pg_hba syntax changes are being entertained, I would love to be able
to set ssl_min_protocol_version locally in a hostssl rule.
Some clients at $work are stuck with ancient SSL libraries, but I would
much rather be able to weaken ssl_min_protocol_version just for them
than do it globally.
Regards,
-Chap
Greetings,
* Chapman Flack (chap@anastigmatix.net) wrote:
If pg_hba syntax changes are being entertained, I would love to be able
to set ssl_min_protocol_version locally in a hostssl rule.Some clients at $work are stuck with ancient SSL libraries, but I would
much rather be able to weaken ssl_min_protocol_version just for them
than do it globally.
This (unlike what was actually proposed) does seem like it'd be a useful
improvement. Not sure exaclty how it would work but I'm generally on
board with the idea.
Thanks,
Stephen
Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 5/13/21 7:38 PM, Bossart, Nathan wrote:
I've attached a small patch that allows specifying only direct members
of a group in pg_hba.conf.Do we really want to be creating two classes of role membership?
Yeah, this seems to be going against the clear meaning of the
SQL spec. I realize you can argue that pg_hba.conf doesn't have
to follow the spec, but it doesn't seem like a terribly good idea
to interpret role membership differently in different places.
Agreed.
The lack of any particular justifcation for wanting this isn't a useful
way to propose a patch either.
Thanks,
Stephen
Stephen Frost <sfrost@snowman.net> writes:
* Chapman Flack (chap@anastigmatix.net) wrote:
If pg_hba syntax changes are being entertained, I would love to be able
to set ssl_min_protocol_version locally in a hostssl rule.
Some clients at $work are stuck with ancient SSL libraries, but I would
much rather be able to weaken ssl_min_protocol_version just for them
than do it globally.
This (unlike what was actually proposed) does seem like it'd be a useful
improvement. Not sure exaclty how it would work but I'm generally on
board with the idea.
Seems like putting GUCs directly into pg_hba would be a mess. Would
it be enough to tell people to use ALTER ROLE/DATABASE SET for this,
and then fix things so that we recheck the protocol version (and
possibly bail out) after absorbing those settings?
I can think of objections to this:
* If you actually want to tie the restriction to source IP addresses,
rather than users or databases, this doesn't get the job done.
* The authentication cycle would be completed (or at least mostly
so) before we bail out; so if the concern is about packet-sniffing
or MITM attacks, maybe this would expose too much.
But it does have the advantage of being something it seems like
we could get done easily.
regards, tom lane
On Fri, May 14, 2021 at 8:58 PM Stephen Frost <sfrost@snowman.net> wrote:
Greetings,
* Chapman Flack (chap@anastigmatix.net) wrote:
If pg_hba syntax changes are being entertained, I would love to be able
to set ssl_min_protocol_version locally in a hostssl rule.Some clients at $work are stuck with ancient SSL libraries, but I would
much rather be able to weaken ssl_min_protocol_version just for them
than do it globally.This (unlike what was actually proposed) does seem like it'd be a useful
improvement. Not sure exaclty how it would work but I'm generally on
board with the idea.
I agree, but I have no idea how you could do that within the current
pg_hba.conf.
The row is selected by the combination of username/database/ipaddress.
But you have to pick the minimum TLS version before the client has
sent that... Basically we have to make the choice long before we've
even started looking at pg_hba.
It would be good to have a way to do it, but I'm not sure pg_hba.conf
is the place for it.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
On 05/17/21 16:15, Magnus Hagander wrote:
The row is selected by the combination of username/database/ipaddress.
But you have to pick the minimum TLS version before the client has
sent that... Basically we have to make the choice long before we've
even started looking at pg_hba.
Use the peer IP address to pre-filter the available pg_hba entries to
those pertaining to that address ... choose a min protocol version that's
the min specified among those ... then get the username and database name
(by which point a protocol has been negotiated), then further filter the
list down to those pertaining to that user and database and allowing that
protocol version?
Yes, clunky, but avoids a more ambitious redesign of pg_hba.
I'm not sure a more ambitious redesign would be a bad thing in principle;
the pg_hba.conf syntax seems rather clunky and limiting to begin with,
and I keep wondering why it isn't in shared tables or something. But
I suppose a lot of external admin tools have some knowledge of it?
Regards,
-Chap
On Mon, May 17, 2021 at 10:31 PM Chapman Flack <chap@anastigmatix.net> wrote:
On 05/17/21 16:15, Magnus Hagander wrote:
The row is selected by the combination of username/database/ipaddress.
But you have to pick the minimum TLS version before the client has
sent that... Basically we have to make the choice long before we've
even started looking at pg_hba.Use the peer IP address to pre-filter the available pg_hba entries to
those pertaining to that address ... choose a min protocol version that's
the min specified among those ... then get the username and database name
(by which point a protocol has been negotiated), then further filter the
list down to those pertaining to that user and database and allowing that
protocol version?Yes, clunky, but avoids a more ambitious redesign of pg_hba.
So you're saying that some entries int he parameter section would
depend on the db/user/ip combo and some would depend just on the ip?
That seems like an absolutely terrible idea to me, especially since
this is about security configuration. Way too easy to get wrong by
people who don't know how the internals work. People will *definitely*
set those parameter thinking that they can do it based on the db and
user as well.
I'm not sure a more ambitious redesign would be a bad thing in principle;
the pg_hba.conf syntax seems rather clunky and limiting to begin with,
and I keep wondering why it isn't in shared tables or something. But
I suppose a lot of external admin tools have some knowledge of it?
I think we'd either need a redesign of that, or a completely different
way of configuring pre-authentication settings.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
On 05/17/21 16:35, Magnus Hagander wrote:
So you're saying that some entries int he parameter section would
depend on the db/user/ip combo and some would depend just on the ip?
I don't *think* that's what I was saying. What I was thinking was this:
The pg_hba.conf file is an ordered list of entries. Each entry can specify
a (broad or narrow) set of IPs it applies to, a (broad or narrow) set of
databases it applies to, and a (broad or narrow) set of users it applies to.
Also, in this hypothetical, it can specify a min protocol version.
Right now, we're doing something like this:
1. accept an incoming connection, learning the client IP
2. SSLRequest message leads to negotiating TLS
3. StartupMessage supplies the desired database and user name
4. pg_hba entries are consulted once and filtered down to the first one
applicable to the client IP, database, and username (and SSLness)
5. that entry is used for authentication
I suggested only:
Insert step 1½, filter the pg_hba entries down to only those that could
possibly accept a connection from this IP address. This is an improper
subset of the whole list, and an improper superset of the singleton to be
generated later in step 4.
Step 2 still negotiates TLS, but can fail early if the protocol would
be older than the oldest allowed in the pre-filtered list.
Step 4 takes that pre-filtered list and completes the restriction down to
first entry matching the IP, database, and username. This should be the
same singleton it would generate now. But it can fail-fast if that entry
would require a higher protocol version than what's been negotiated,
before sending the corresponding authentication request message, so no
authentication data will be exchanged over a less-secure channel than
intended. However, the user, database name, and options in the Startup
message might have been exposed over a lower TLS version than intended.
Maybe that's not the end of the world?
Regards,
-Chap
Chapman Flack <chap@anastigmatix.net> writes:
On 05/17/21 16:35, Magnus Hagander wrote:
So you're saying that some entries int he parameter section would
depend on the db/user/ip combo and some would depend just on the ip?
I don't *think* that's what I was saying. What I was thinking was this:
...
This seems pretty horrid to me, not only from a complexity standpoint,
but because it would break the principle that pg_hba.conf entries are
applied in order.
On the whole, I'm afraid that this idea is going to create a lot
more problems than it solves.
regards, tom lane
On 05/17/21 17:55, Tom Lane wrote:
This seems pretty horrid to me, not only from a complexity standpoint,
but because it would break the principle that pg_hba.conf entries are
applied in order.
This makes twice in a row that I've failed to see how.
If you go through the entries, in order, and simply prune from the list
the ones you can already prove would never apply to this connection, how
does that break the ordering principle?
Regards,
-Chap
On 05/17/21 21:19, Chapman Flack wrote:
This makes twice in a row that I've failed to see how.
If you go through the entries, in order, and simply prune from the list
the ones you can already prove would never apply to this connection, how
does that break the ordering principle?
Ok, I see how what I proposed looks out-of-order just in that it lets the
initial TLS negotiation be influenced by the minimum version over all
potentially-applicable entries.
But that's just an optimization anyway. The same ultimate effect would be
achieved by unconditionally allowing anything back to TLSv1 to be negotiated
at SSLRequest time, and then (processing the entries in order as always)
rejecting the connection if the first one that could apply expects a higher
protocol version.
The pre-scan and use of the minimum version encountered has only the effect
of fast-failing a TLS negotiation for a version that won't possibly succeed.
Regards,
-Chap
On Mon, May 17, 2021 at 11:18 PM Chapman Flack <chap@anastigmatix.net> wrote:
On 05/17/21 16:35, Magnus Hagander wrote:
So you're saying that some entries int he parameter section would
depend on the db/user/ip combo and some would depend just on the ip?I don't *think* that's what I was saying. What I was thinking was this:
The pg_hba.conf file is an ordered list of entries. Each entry can specify
a (broad or narrow) set of IPs it applies to, a (broad or narrow) set of
databases it applies to, and a (broad or narrow) set of users it applies to.Also, in this hypothetical, it can specify a min protocol version.
Right now, we're doing something like this:
1. accept an incoming connection, learning the client IP
2. SSLRequest message leads to negotiating TLS
3. StartupMessage supplies the desired database and user name
4. pg_hba entries are consulted once and filtered down to the first one
applicable to the client IP, database, and username (and SSLness)
5. that entry is used for authenticationI suggested only:
Insert step 1½, filter the pg_hba entries down to only those that could
possibly accept a connection from this IP address. This is an improper
subset of the whole list, and an improper superset of the singleton to be
generated later in step 4.Step 2 still negotiates TLS, but can fail early if the protocol would
be older than the oldest allowed in the pre-filtered list.
Nop, this is *exactly* what I'm referring to as being a bad idea.
Step 1 1/2 in this *ignores* the fact that you may have specified a
restriction on username and database name in pg_hba.conf, because it
hasn't seen them yet. Thus, a parameter such as min_tls_version would
not respect the username/databasename field, whereas other parameters
would. That is a massive risk of misconfiguration.
I mean, if you have
hostssl somedatabase someuser 10.0.0.0/24 gss
hostssl somedatabase supseruser 10.0.0.0/24 gss tls_min_version=1.3
One would reasonably expect that "someuser" can connect with whatever
the default version i for tls_min_versino, whereas "superuser" would
require a minimum of 1.3. But that's *not* what would happen --
superuser would also be allowed to connect with a lower version if
that's allowed in the global set.
Step 4 takes that pre-filtered list and completes the restriction down to
first entry matching the IP, database, and username. This should be the
same singleton it would generate now. But it can fail-fast if that entry
would require a higher protocol version than what's been negotiated,
before sending the corresponding authentication request message, so no
authentication data will be exchanged over a less-secure channel than
intended. However, the user, database name, and options in the Startup
message might have been exposed over a lower TLS version than intended.
Maybe that's not the end of the world?
That is exactly the problem. And while that may hold true of current
auth methods, it may not hold true of all. And it could still trigger
things like an ident callback if that is allowed etc.
So I stand by thinking this is the wrong place to solve the problem. I
agree it would be good to be able to do it, but I don't agree on
overloading it on pg_hba.conf, which is complicated enough already.
And for security config, simplicity is pretty much always better.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
On 05/18/21 04:54, Magnus Hagander wrote:
I mean, if you have
hostssl somedatabase someuser 10.0.0.0/24 gss
hostssl somedatabase supseruser 10.0.0.0/24 gss tls_min_version=1.3One would reasonably expect that "someuser" can connect with whatever
the default version i for tls_min_versino, whereas "superuser" would
require a minimum of 1.3. But that's *not* what would happen --
superuser would also be allowed to connect with a lower version if
that's allowed in the global set.
Negatory. "superuser" would be allowed to send a StartupMessage
containing the strings "somedatabase" and "superuser" (and possibly
some settings of options) over a lower version if that's allowed
in the global set ... and would then have the connection rejected
because the negotiated protocol was lower than 1.3, without seeing
any authentication message or having a chance to send any sensitive
authentication credentials.
So the risk of any information exposure over a too-low TLS version
is limited to the name of a database, the name of a user, and possibly
the settings of some options, and no sensitive authentication data.
Regards,
-Chap
On 5/18/21 8:05 AM, Chapman Flack wrote:
On 05/18/21 04:54, Magnus Hagander wrote:
I mean, if you have
hostssl somedatabase someuser 10.0.0.0/24 gss
hostssl somedatabase supseruser 10.0.0.0/24 gss tls_min_version=1.3One would reasonably expect that "someuser" can connect with whatever
the default version i for tls_min_versino, whereas "superuser" would
require a minimum of 1.3. But that's *not* what would happen --
superuser would also be allowed to connect with a lower version if
that's allowed in the global set.Negatory. "superuser" would be allowed to send a StartupMessage
containing the strings "somedatabase" and "superuser" (and possibly
some settings of options) over a lower version if that's allowed
in the global set ... and would then have the connection rejected
because the negotiated protocol was lower than 1.3, without seeing
any authentication message or having a chance to send any sensitive
authentication credentials.So the risk of any information exposure over a too-low TLS version
is limited to the name of a database, the name of a user, and possibly
the settings of some options, and no sensitive authentication data.
We are way off $subject. If we want to continue this discussion please
use an appropriate subject.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com