"Marko Kreen" <[EMAIL PROTECTED]> writes: > On 7/21/08, Tom Lane <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers