On 7/22/08, Andrew Sullivan <ajs@commandprompt.com> wrote:
> 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. . .
For that you need to overwrite the plproxy.get_cluster_partitions()
function or the data it operates on.
I don't see any hole in this, unless explicitly created.
> > > 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).
For that the system2 needs to be added as partion to a cluster.
Or specified explicitly in CONNECT statement.
And user can execute only pre-determines queries/functions on system2.
> > 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.
Do you still see a big hole?
--
marko
