Re: [patch] plproxy v2 - Mailing list pgsql-hackers

From Andrew Sullivan
Subject Re: [patch] plproxy v2
Date
Msg-id 20080722143949.GE58564@commandprompt.com
Whole thread Raw
In response to Re: [patch] plproxy v2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [patch] plproxy v2  ("Marko Kreen" <markokr@gmail.com>)
Re: [patch] plproxy v2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jul 21, 2008 at 09:32:57PM -0400, Tom Lane wrote:
> "Marko Kreen" <markokr@gmail.com> writes:

> > 2.  If cluster connection strings do not have 'user=' key,
> >     ' user=' || current_username() is appended to it.
> 
> Cool, I missed that.  At minimum the documentation has to explain this
> point and emphasize the security implications.  Is it a good idea
> to allow user= in the cluster strings at all?

I wondered about this myself.  Is there anything at all preventing me
from doing 'user=' for some other user?  If not. . .

> >     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.

. . .this means that any user on system1 for which there is at least
one user on system2 with plproxy access automatically also has that
access on system2.  (Plus what Tom noted).

> We regularly get beat up about any aspect of our security apparatus
> that isn't "secure by default".  This definitely isn't, and from
> a PR point of view (if nothing else) that doesn't seem a good idea.

I'm less worried about the PR, and more worried about the truck-sized
hole this opens in any authentication controls.  It seems to me that
it's a fairly serious problem.

A

-- 
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/


pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: [WIP] collation support revisited (phase 1)
Next
From: Zdenek Kotala
Date:
Subject: Re: pltcl_*mod commands are broken on Solaris 10