"Stephen Frost" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
