| From: | Julian Markwort <julian(dot)markwort(at)uni-muenster(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] pgpassfile connection option |
| Date: | 2016-10-04 11:42:26 |
| Message-ID: | ab86aa47-9c24-3fe9-378a-2eb353ecf608@uni-muenster.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 09/26/2016 07:51 PM, Robert Haas wrote:
> However, they don't have
> to accept the possibility that arbitrary local files readable by the
> user ID will be used for authentication and/or disclosed; this patch
> would force them to accept that risk.
I do agree with you, however we might have to take a look at the
parameter sslkey's implementation here as well - There are no checks in
place to stop you from using rogue sslkey parameters.
I'd like to suggest having both of these parameters behave in a similar
fashion. In order to achieve safe behaviour, we could implement the use
of environment variables prohibiting the use of user-located pgpassfiles
and sslkeys.
How about PGSECRETSLOCATIONLOCK ?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2016-10-04 11:47:29 | Re: Logical tape pause/resume |
| Previous Message | Etsuro Fujita | 2016-10-04 11:30:18 | Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan. |