Re: Re[2]: Restricting queries by the presence of a WHERE clause

From: Lincoln Yeoh <lylyeoh(at)mecomb(dot)com>
To: jwm(at)plain(dot)co(dot)nz, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Re[2]: Restricting queries by the presence of a WHERE clause
Date: 2000-06-29 01:09:19
Message-ID: 3.0.5.32.20000629090919.00925d90@pop.mecomb.po.my
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> > webclient <---> proxy <---> Postgres
>
>Ok. Pluses:
>
>- The standalone program is easier to hack together than delving into the
> database I could probably just hack on SQL Relay or something.
>- The proxy can be as tightly secured as the database without losing
> functionallity, as it only needs to accept a connection from the secure
> web server.
>
>Minuses:
>
>- Another machine to buy
>- Root on the proxy is as bad as root was on the secure server, so..
>- The simple hack will need thorough security auditing
>- It's yet another machine to secure.
>- It's yet another point of failure.

If you're not too afraid you could try running the proxy server on the
database.

Check out Perl's DBD Proxy and Server. I believe you can use it to limit
the sort of queries that go through. In fact you could probably use it
write a proxy which only does a handful of queries - where the SQL is
prestored/hardcoded in the proxy, so in effect all the client can supply
are the parameters.

Now, the question is - would the DBD proxy be fast, robust and safe enough
for you...

Also another issue is you will probably need to use perl at the relevant
webapps- the client (webapp) will use DBD proxy to talk to DBD server which
will then talk to the actual database.

Cheerio,
Link.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Richard Harvey Chapman 2000-06-29 01:14:25 pg_atoi()
Previous Message John Morton 2000-06-29 00:23:53 Re[2]: Restricting queries by the presence of a WHERE clause