On 7/22/08, Marko Kreen <[EMAIL PROTECTED]> wrote: > On 7/22/08, Tom Lane <[EMAIL PROTECTED]> wrote: > > "Marko Kreen" <[EMAIL PROTECTED]> writes: > > > Also, plroxy does > > > _nothing_ with passwords. That means the password for remote > > > connection must be in postgres user's .pgpass, > > > > > > That seems *exactly* backwards, because putting the password in postgres > > user's .pgpass is as good as disabling password auth altogether. > > Consider that it would also hand all the keys to the kingdom over to > > someone who had access to dblink on the same machine (not even the same > > cluster, so long as it was run by the same postgres user!). > > Good point.
I happened to take a look at dblink and I'm not convinced anymore. Any untrusted PL can be used for remote calls and in all cases, including PL/Proxy, the superuser must create the function that specifies both connect string and query. To allow regular user specify either connect string or query, the superuser must take explicit action by coding the function that way. But for dblink, the *normal* mode of action is that regular user can (heh, *must*) specify both connect string and query... And the require-password-hack for dblink makes things only worse as it obfuscates the security implications of using it. So indeed, there is a "hole a truck can drive through" and it's called 'dblink'. And I don't I should make life miserable for PL/Proxy users just because core has merged insecure module. Currently the PL/Proxy acts the same as any other libpq-using PL, using .pgpass is quite natural for them and I don't see any reason to lock it down further for no good reason. I know you had a fiasco with dblink security already, but PL/Proxy is not in dblink camp. It's in untrusted-PL camp. So, now we have clear technical argument for immediate merge - as a replacement for dblink, as it's more secure and better designed. And only thing PL/Proxy really needs is more documentation, there needs to be list of various ways to set it up and security implications of each. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers