"Tom Lane" <[EMAIL PROTECTED]> writes: > As for inside connections, "secure" is still largely dependent on what your > threat model is.
Indeed I think closing Postgres to access based on the unix userid of the connecting user is the wrong threat model. That's basically saying you don't trust the unix userid of the system in which case you're really up a creek. On the other hand dblink allows something that most sysadmins would consider outside the normal bounds and of concern in their threat model. It allows a privilege escalation since it allows any user to make an arbitrary TCP unix connection as another user. I think that's the angle this should be closed from. Put another way there is a fundamental incompatibility between the default settings for Postgres and the default settings for dblink though. If you install both and accept the default configuration for both then one subverts the security of the other. The side that's outside the norm here is dblink, and in fact it not only subverts Postgres but could allow an attacker to subvert other systems' security too. All that really has to happen is that dblink should by default not be callable by any user other than Postgres. DBAs should be required to manually run "GRANT EXECUTE ON dblink_connect(text) TO public;" if that's what he wants. It would be more obvious running that command that you're allowing any user to make connections as Postgres, and at least whatever piece of documentation contains that instruction would be a convenient place to put a warning about it. The only problem with this is that dblink provides 36 different functions (why so many?!) My first thought is it could provide a pair of plpgsql functions to grant or revoke access to all its functions to a specified role. But perhaps someone else has a cleverer idea. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org