On 7/22/08, Andrew Sullivan <[EMAIL PROTECTED]> wrote: > On Mon, Jul 21, 2008 at 09:32:57PM -0400, Tom Lane wrote: > > "Marko Kreen" <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
