> 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
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
