"Tom Lane" <[EMAIL PROTECTED]> writes: > I like this approach better than removing public execute privileges > on the functions, for two reasons: > > * A routine minor version update would install the security fix into > existing installations, without need for any DBA intervention. > > * It does not take away functionality that has perfectly legitimate uses.
I think there are two problems with this: a) dblink still shouldn't allow arbitrary users to open arbitrary tcp/ip sockets or unix sockets from the server. That's still a security threat even if we close Postgres's vulnerability to it. Even if libpq prevents you from doing much because it looks for the libpq protocol messages it would still allow, for example, an attacker to do a port probe and see what services are running on other hosts on the internal network. b) For a situation like a homebrew replication system someone may want to have set up a second server which allows passwordless access from the first server. In which case it is entirely sane (though it doesn't seem to be the best idea imho) to use ident and requiring a password is removing functionality that has a perfectly legitimate use. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
