Connecting using an existing socket (libpq).

[jbi130]

I have a 3 tier client/server application where the client connection
to the server which then uses PostgreSQL. I'd like to extend the
client to have direct access to PostgreSQL but do not want to open up
postgresql to the internet.

So, I'd like to tunnel the libpq connection over the existing secure
socket. My preferred solution would be for the client to pass libpq
an already connected file descriptor (so I can prevent binding a port
to localhost).

Is such a thing possible without hacking libpq? Are there other
options I should be looking at that don't involve PostgreSQL listening
on the evil internet?

Thanks.

[Keith C. Perry]

Quoting jb****@yahoo.com:

I have a 3 tier client/server application where the client connection
to the server which then uses PostgreSQL. I'd like to extend the
client to have direct access to PostgreSQL but do not want to open up
postgresql to the internet.

So, I'd like to tunnel the libpq connection over the existing secure
socket. My preferred solution would be for the client to pass libpq
an already connected file descriptor (so I can prevent binding a port
to localhost).

Is such a thing possible without hacking libpq? Are there other
options I should be looking at that don't involve PostgreSQL listening
on the evil internet?

Thanks.
I'm not sure if you could "tunnel" that connection in the way you're saying
because that connection terminates at (I'm assumming) your application server
and not the db server. At a minimum, I would think you would have to write
logic on the application sure to proxy the management traffic over to the db.
Seems messy but I think there are other options for you:

1) If you have compiled with SSL then you can enforce SSL connections for non
local network connections. You'd have to open up the database tcp/ip port on
your firewall which it sounds like you don't want to do. Keep in mind that the
PG port is arbitrary so you could run it on something none standard.

2) If you have a decide NAT/firewall system (e.g. Iptables on Linux) you could
do port forwarding. So even the db has a public nic, you could then set up and
IP/port only used for db management which then would be translated to real db
IP/port. Again, you would (should) only run this with clients like pgadmin.

That is pretty specific to PG but if your clients are Linux, then you can use
SSH port forward to tunnel anything you want. This is more complicated but in
the end is more flexible since there are no server side changes necessary and
non-ssl clients can be used.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

--
Keith C. Perry, MS E.E.
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org