On Tue, Oct 4, 2016 at 7:42 AM, Julian Markwort <julian.markw...@uni-muenster.de> wrote: > 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 ?
You could do something like that, I guess, but I think it might be a good idea to wait and see if anyone else has opinions on (1) the desirability of the basic feature, (2) the severity of the security hazard it creates, and (3) your proposed remediation method. So far I don't see anybody actually endorsing your proposal here, which might mean that any patch you produce will be rejected on the grounds that nobody has a clear use case for this feature. Hey, everybody: chime in here... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
