From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(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:14:29 |
Message-ID: | 200801150414.m0F4ETL26035@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Yea, I figured using protected directories for the socket was the
> > zero-cost solution, and if you have to do SSL, might as well just use
> > TCP too. (If you moved the socket file to a protected directory I think
> > you could use external_pid_file='/tmp/.s.PGSQL.5432' to prevent a spoof
> > socket file in /tmp. Should we document that idea?)
>
> Umm ... two questions about that:
>
> * will the postmaster fail if there's a socket where it tries to write
> the external_pid_file? (If it does fail, does that really fix
> anything? The spoofer already owns the socket.)
I figured it would prevent someone from spoofing while the server was
up, which is a _new_ problem when moving the socket. :-(
My feeling on the moving of sockets risk is that you are probably going
to have all your clients using the new socket directory before anyone
tries to put something in /tmp, especially if you have the lock file in
/tmp as outlined above. To spoof in such a situation you would need to
do the attack while the server is down _and_ against a client that
doesn't know the right socket location.
> * if there's a plain file where a client expects to find the socket,
> what happens? (Probably nothing very good, since the first thing the
> client will do is write on it.)
We would have to test that.
> >> If we do want to apply Peter's patch, I think it needs to be extended so
> >> that the default behavior on sockets is the same as before, ie, no SSL.
>
> > That seems like it is going to be added confusion; just using the
> > protected socket diretory or TCP & SSL seems less error-prone.
>
> 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.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-01-15 04:31:06 | Array behavior oddities |
Previous Message | Kris Jurka | 2008-01-15 03:51:55 | Re: Pl/Java broken since Postgresql 8.3-rc1 |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-01-15 04:35:30 | Re: SSL over Unix-domain sockets |
Previous Message | Tom Lane | 2008-01-15 03:33:28 | Re: SSL over Unix-domain sockets |