Re: dblink connection security

"Stephen Frost" <sfrost(at)snowman(dot)net> writes:

>> Being able to connect to a postgres server shouldn't mean being able to open
>> tcp connections *from* that server to arbitrary other host/ports. Consider for
>> example that it would allow a user to perform a port scan from inside your
>> network to see what internal services are running.
>
> I'm in agreement with Greg. It's a poor idea, overall, to allow users
> to initiate TCP connections from the backend. That should be a
> superuser-only ability and should require security definer functions
> with appropriate safe-guards (which would be site-specific) to be
> created by the end admins.

I think we rejected that idea as making it super-user-only would cause
problems for existing installs. It would also take away the possibility for
users to use the compromise policy the patch implements which is the most
useful policy for many installs where the users have shell accounts anyways.

I was only suggesting that we add the patch *and* revoke execute bits for
public in the dblink install script. Existing installs would just get the
benefit of the patch and continue to function.

Actually from a security point of view revoking public execute is pretty much
the same as making a function super-user-only. The only difference is how much
of a hassle it is for the super-user to grant access. Perhaps we should
reconsider whether any of the other super-user-only functions should be simply
not executable by default but work normally if granted.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com