On 7/22/08, Marko Kreen <markokr@gmail.com> wrote:
> On 7/22/08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > "Marko Kreen" <markokr@gmail.com> 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
