Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings
Date
Msg-id 20200109103014.GA4192@msg.df7cb.de
Whole thread Raw
In response to Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings  (Christoph Berg <myon@debian.org>)
Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings  (Christoph Berg <myon@debian.org>)
Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Re: Andrew Dunstan 2019-11-01 <f941b95e-27ad-cb5c-2495-13c44f90b1bc@2ndQuadrant.com>
>          {"password_required", UserMappingRelationId, false},
> +        /*
> +         * Extra room for the user mapping copies of sslcert and sslkey. These
> +         * are really libpq options but we repeat them here to allow them to
> +         * appear in both foreign server context (when we generate libpq
> +         * options) and user mapping context (from here). Bit of a hack
> +         * putting this in "non_libpq_options".
> +         */
> +        {"sslcert", UserMappingRelationId, true},
> +        {"sslkey", UserMappingRelationId, true},

Nice feature, we were actually looking for exactly this yesterday.

I have some concerns about security, though. It's true that the
sslcert/sslkey options can only be set/modified by superusers when
"password_required" is set. But when password_required is not set, any
user and create user mappings that reference arbitrary files on the
server filesystem. I believe the options are still used in that case
for creating connections, even when that means the remote server isn't
set up for cert auth, which needs password_required=false to succeed.

In short, I believe these options need explicit superuser checks.

Christoph



pgsql-hackers by date:

Previous
From: Rafia Sabih
Date:
Subject: Re: [Logical Replication] TRAP: FailedAssertion("rel->rd_rel->relreplident== REPLICA_IDENTITY_DEFAULT || rel->rd_rel->relreplident ==REPLICA_IDENTITY_FULL || rel->rd_rel->relreplident == REPLICA_IDENTITY_INDEX"
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Block level parallel vacuum