Re: [patch] plproxy v2

On 7/21/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Marko Kreen" <markokr(at)gmail(dot)com> writes:
> > [ plproxy ]
>
> I looked through this a bit, and my principal reaction was "what are
> the security implications?" It seems like it'd be very easy to create
> functions that allow untrusted users to execute arbitrary SQL on
> other databases in the plproxy cluster. As far as I saw there was
> no privilege-checking within plproxy itself, you were just relying
> on SQL-level permissions checking --- so even though plproxy functions
> can only be *created* by superusers, by default they can be *used* by
> anybody. So it'd take a great deal of care to avoid making
> unintentional security holes.
>
> I'm not sure about a good solution to this problem, but I think it needs
> to be solved before plproxy can be recommended for widespread use.
> The first thought that comes to mind is to somehow propagate the userid
> on the calling server to the execution on the remote, so that a user
> can't get more privilege on the remote than if he were executing there
> directly. I'm imagining that the definition of a cluster would include
> a map from local to remote userids (and thereby imply that anyone not
> explicitly listed can't do remote access at all).

There are 2 aspects to it:

1. Function can be created only by superuser.
2. If cluster connection strings do not have 'user=' key,
' user=' || current_username() is appended to it. Note that
connections are per-backend, not shared. Also, plroxy does
_nothing_ with passwords. That means the password for remote
connection must be in postgres user's .pgpass, or there
is pooler between plproxy and remote database who handles
passwords.

What else do you see is needed? I'm not sure a map is a good idea,
is seems to create unnecessary coplexity. Ofcourse, it can be done.

But I don't think plproxy can and should protect dumb admins who
create remote_exec(sql) function and allow untrusted users to
execute it.

--
marko