Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings
От | Christoph Berg |
---|---|
Тема | Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings |
Дата | |
Msg-id | 20200109103014.GA4192@msg.df7cb.de обсуждение исходный текст |
Ответ на | Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Ответы |
Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings
Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings |
Список | 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 по дате отправления: