Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To:
Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc:
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Huxton <dev(at)archonet(dot)com>,
"Thomas T(dot) Veldhouse" <veldy(at)veldy(dot)net>, pgsql-general(at)postgresql(dot)org
> Bruce Momjian writes:
>
> > Does anyone have a comment on this? I wrote it a month ago.
>
> The fact that the database server is wide-open in the default installation
> is surely not good, but the problem is that we don't have a universally
> accepted way to lock it down. We could make password authentication the
> default, but that would annoy a whole lot of people. Another option would
> be to set the unix domain socket permissions to 0200 by default, so only
> the user that's running the server can get in. I could live with that;
> not sure about others.
Whatever you suggest. We basically create a world-writeable
socket/database when we do initdb. It is similar to a product
installing in a world-writable directory.
I realize you can lock it down later, but it seems people need to lock
it down _before_ doing initdb or somehow keep it locked down until they
set security. Our new SO_PEERCRED/SCM_CREDS gives us a lockdown option
on Linux/BSD platforms, but not on the others.
If we do the socket permissions thing for initdb, when do we start
setting the socket permissions properly?
I realize there is no easy answer. I just wanted people to know this is
a security hole.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
