From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Mark Mielke <mark(at)mark(dot)mielke(dot)cc>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SSL over Unix-domain sockets |
Date: | 2008-01-15 04:35:30 |
Message-ID: | 12842.1200371730@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> Yeah, all of this is about confusion and error-proneness. I still think
>> that the real problem is that we don't have full control over
>> client-side code, and therefore can't just write off the problem of a
>> client deciding to connect to /tmp/.s.PGSQL.5432 even if the local DBA
>> thinks the socket would be safer elsewhere.
> Right. I think the lock file in /tmp does help somewhat.
Even if it happens to work (on some platforms) it seems like a kluge.
It strikes me that given the postmaster's infrastructure for listening
on multiple sockets, it would be a pretty small matter of programming
to teach it to listen on socket files in multiple directories not only
one. If we had that, the postmaster could listen in both /tmp and
your-more-secure-directory-of-choice. Surely an actual socket file
would be a more useful "blocker" in /tmp than a dead-weight PID file.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-01-15 04:50:22 | Re: Array behavior oddities |
Previous Message | Bruce Momjian | 2008-01-15 04:31:06 | Array behavior oddities |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-01-15 09:10:37 | Re: SSL over Unix-domain sockets |
Previous Message | Bruce Momjian | 2008-01-15 04:14:29 | Re: SSL over Unix-domain sockets |