"Marko Kreen" <markokr@gmail.com> writes:
> On 7/21/08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I looked through this a bit, and my principal reaction was "what are
>> the security implications?
> There are 2 aspects to it:
> 1. Function can be created only by superuser.
What I'm concerned about is who they can be *called* by. I'd be happier
if the default behavior was that there was no public execute privilege
for plproxy functions.
I think right now that could be enforced by having plproxy's validator
procedure replace any null proacl entry with something that explicitly
refuses public execute. That's a bit of a hack though. Maybe it'd be
worth inventing per-PL default ACLs, instead of having a
one-size-fits-all policy?
> 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?
> 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!).
> 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.
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 repeat that I don't feel comfortable in the least with plproxy's
security model.
regards, tom lane