Specification of "/" in the host name (for Unix socket support)

Hi,

We are trying to add support for Unix sockets to the current jdbc (for
our own release for now). The support is added via gnu classpath,located
at: http://www.nfrese.net/software/gnu_net_local/overview.html

Since Unix sockets require specification of path to the socket, the url
would be something like: jdbc:postgresql:///tmp:5432/template1...

However, since the path starts with a "/" which is a token separator,
parseURL in Driver.java cannot handle it, and sets the host to "/". To
find possible solutions, we referred to the URL RFC located at:
http://www.w3.org/Addressing/rfc1738.txt

Section 5, the BNF mentions that "% <hex> <hex>" is an escaped
character. We are thinking of implementing a similar idea for the jdbc
url. i.e. the URL jdbc:postgresql:///tmp:5432/template1... would have to
be specified as jdbc:postgresql://%2Ftmp:5432/template1... , 2F being
the ascii code for "/" in hex. This would of course necessitate the
addition of an extra function for parsing tokens but it would be fairly
simple to implement.

Does the above mentioned approach seem reasonable or is there another
format that should be followed?

Thanks,
Deepak

--
Deepak Bhole <dbhole(at)redhat(dot)com>
Red Hat Canada Ltd.

On 12/09/2003 20:20 Deepak Bhole wrote:
>
> Hi,
>
> We are trying to add support for Unix sockets to the current jdbc
> (for
> our own release for now). The support is added via gnu classpath,located
> at: http://www.nfrese.net/software/gnu_net_local/overview.html
>
> Since Unix sockets require specification of path to the socket,
> the url
> would be something like: jdbc:postgresql:///tmp:5432/template1...

Why on earth are you trying to pollute the JDBC driver with
platform-specific non-portable features that can be of no possible benefit
to anyone except commercial companies attempting to use any underhanded
means to lock customers into their product? Are you trying be the new
Microsoft?

Get real. If Red Hat want to improve the JDBC driver, the ability to
properly use server side prepared statements from a JDBC connection pool
would give a massively bigger performance gain that anything you possibly
ever get between tcp/ip and unix sockets. Can you see why I'm so
suspicious about the companies motives? (excludes alternative explaination
that you don't have a clue...)

And just for the record, I'm 100% Red Hat Linux user.

--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants |
http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+---------------------------------------------+

Paul Thomas <paul(at)tmsl(dot)demon(dot)co(dot)uk> writes:
> On 12/09/2003 20:20 Deepak Bhole wrote:
>> We are trying to add support for Unix sockets to the current jdbc
>> (for
>> our own release for now). The support is added via gnu classpath,located
>> at: http://www.nfrese.net/software/gnu_net_local/overview.html

> Why on earth are you trying to pollute the JDBC driver with
> platform-specific non-portable features that can be of no possible benefit
> to anyone except commercial companies attempting to use any underhanded
> means to lock customers into their product? Are you trying be the new
> Microsoft?

You got up on the wrong side of the bed today? What's platform-specific
about Unix sockets?

> Get real. If Red Hat want to improve the JDBC driver, the ability to
> properly use server side prepared statements from a JDBC connection pool
> would give a massively bigger performance gain that anything you possibly
> ever get between tcp/ip and unix sockets.

Deepak did not state or imply that the motivation for this was performance.
Actually, it's security: lots of people prefer to run their PG servers
with no open TCP ports at all. So it would be good if JDBC could talk
to such a server.

> Can you see why I'm so suspicious about the companies motives?

I'm suspicious about *you*. Who are you to tell other people how to
spend their time? And in such an impolite fashion?

> And just for the record, I'm 100% Red Hat Linux user.

Just for the record, I work for Red Hat.

regards, tom lane

On Fri, Sep 12, 2003 at 03:20:49PM -0400, Deepak Bhole wrote:
>
> Hi,
>
> We are trying to add support for Unix sockets to the current jdbc (for
> our own release for now). The support is added via gnu classpath,located
> at: http://www.nfrese.net/software/gnu_net_local/overview.html
>
> Since Unix sockets require specification of path to the socket, the url
> would be something like: jdbc:postgresql:///tmp:5432/template1...
>
> However, since the path starts with a "/" which is a token separator,
> parseURL in Driver.java cannot handle it, and sets the host to "/". To
> find possible solutions, we referred to the URL RFC located at:
> http://www.w3.org/Addressing/rfc1738.txt
>
> Section 5, the BNF mentions that "% <hex> <hex>" is an escaped
> character. We are thinking of implementing a similar idea for the jdbc
> url. i.e. the URL jdbc:postgresql:///tmp:5432/template1... would have to
> be specified as jdbc:postgresql://%2Ftmp:5432/template1... , 2F being
> the ascii code for "/" in hex. This would of course necessitate the
> addition of an extra function for parsing tokens but it would be fairly
> simple to implement.
>
> Does the above mentioned approach seem reasonable or is there another
> format that should be followed?

Have you considered using something like "jdbc:postgresql-unix:...." and
having the parser handle the two cases separately? It's a different
communication path, after all .. "host" and "port" doesn't make much sense
for unix sockets. i.e. use something like:

jdbc:postgresql-unix:///var/run/postgresql/.s.PGSQL.5432/template1

In fact, since this isn't a network protocol at all, how about dropping the
"common internet scheme syntax" altogether in favour of clarity:

jdbc:postgresql-unix:/var/run/postgresql/.s.PGSQL.5432:template1

-O

Overall I concur with what Oliver is suggesting here. However I
slightly prefer the URL RFC compatible syntax.

jdbc:postgresql-unix:///path/to/socket/database

thanks,
--Barry

Oliver Jowett wrote:
> On Fri, Sep 12, 2003 at 03:20:49PM -0400, Deepak Bhole wrote:
>
>>Hi,
>>
>> We are trying to add support for Unix sockets to the current jdbc (for
>>our own release for now). The support is added via gnu classpath,located
>>at: http://www.nfrese.net/software/gnu_net_local/overview.html
>>
>> Since Unix sockets require specification of path to the socket, the url
>>would be something like: jdbc:postgresql:///tmp:5432/template1...
>>
>> However, since the path starts with a "/" which is a token separator,
>>parseURL in Driver.java cannot handle it, and sets the host to "/". To
>>find possible solutions, we referred to the URL RFC located at:
>>http://www.w3.org/Addressing/rfc1738.txt
>>
>> Section 5, the BNF mentions that "% <hex> <hex>" is an escaped
>>character. We are thinking of implementing a similar idea for the jdbc
>>url. i.e. the URL jdbc:postgresql:///tmp:5432/template1... would have to
>>be specified as jdbc:postgresql://%2Ftmp:5432/template1... , 2F being
>>the ascii code for "/" in hex. This would of course necessitate the
>>addition of an extra function for parsing tokens but it would be fairly
>>simple to implement.
>>
>> Does the above mentioned approach seem reasonable or is there another
>>format that should be followed?
>
>
> Have you considered using something like "jdbc:postgresql-unix:...." and
> having the parser handle the two cases separately? It's a different
> communication path, after all .. "host" and "port" doesn't make much sense
> for unix sockets. i.e. use something like:
>
> jdbc:postgresql-unix:///var/run/postgresql/.s.PGSQL.5432/template1
>
> In fact, since this isn't a network protocol at all, how about dropping the
> "common internet scheme syntax" altogether in favour of clarity:
>
> jdbc:postgresql-unix:/var/run/postgresql/.s.PGSQL.5432:template1
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>

On 13/09/2003 00:53 Tom Lane wrote:
> Paul Thomas <paul(at)tmsl(dot)demon(dot)co(dot)uk> writes:
> > On 12/09/2003 20:20 Deepak Bhole wrote:
> >> We are trying to add support for Unix sockets to the current jdbc
> >> (for
> >> our own release for now). The support is added via gnu
> classpath,located
> >> at: http://www.nfrese.net/software/gnu_net_local/overview.html
>
> > Why on earth are you trying to pollute the JDBC driver with
> > platform-specific non-portable features that can be of no possible
> benefit
> > to anyone except commercial companies attempting to use any underhanded
>
> > means to lock customers into their product? Are you trying be the new
> > Microsoft?
>
> You got up on the wrong side of the bed today? What's platform-specific
> about Unix sockets?

Well, Sun must regard them as pretty platform-specific as they're not part
of the Java spec. In practice there's another issue. Its called binary
compability. PostgreSQL users currently have the luxury of a type-4 (i.e.,
pure Java) JDBC driver. So a driver can be built on a Linux box (for
example) and that binary will also run on Windows, Solaris... Unix sockets
would have to be accessed though JNI thus making the driver a type-3
driver. Kiss goodbye to binary portability. And forget running the driver
on Windows without (I would imagine) cygwin installed - and that would
re-map to tcp/ip sockets "pretending" to be unix sockets - can't see much
advantage in that one. Forget using JDBC from applets to as that requires
a type-4 driver. Not that I would imagine that there are many people doing
JDBC from applets but the ability is there ATM. That kind of portability I
live without!

It really alarms me to think that the type-4 driver might get "demoted" to
type-3:

"(for our own release for now)"
~~~~~~~

I've had some really bad experiece of type-3 drivers over last couple of
years, especially regarding VM crashes :(. I'm sure a lot of this is
because JNI can be a real b*****d to debug rather that any reflection on
the programmers. Not that that's of any comfort to the users of a web
application which crashes twice a day.

> > Get real. If Red Hat want to improve the JDBC driver, the ability to
> > properly use server side prepared statements from a JDBC connection
> pool
> > would give a massively bigger performance gain that anything you
> possibly
> > ever get between tcp/ip and unix sockets.
>
> Deepak did not state or imply that the motivation for this was
> performance.
> Actually, it's security: lots of people prefer to run their PG servers
> with no open TCP ports at all. So it would be good if JDBC could talk
> to such a server.

You can hide the port from the outside world with a firewall and configure
PostgreSQL to only accept tcp/ip connections for 127.0.0.1. And if packet
sniffing on the loopback interface is a concern, is SSL not secure enough?
Having said that, I'm not sure if the JDBC driver supports SSL ATM but
even without it the security argument (as opposed to a dogmatic policy
stance) looks very weak to me which is why I initially discounted it.

> > Can you see why I'm so suspicious about the companies motives?
>
> I'm suspicious about *you*. Who are you to tell other people how to
> spend their time? And in such an impolite fashion?

I haven't told anybody to do anything and any issues regarding politeness
or otherwise are entirely your own interpretation.

>
> > And just for the record, I'm 100% Red Hat Linux user.
>
> Just for the record, I work for Red Hat.

I'm aware of that. But you need to be aware that:

a) the view of your company you get from the inside may be somewhat
different from the view that outsiders get

b) not everyone on the planet automatically assumes that the management of
your, or any other, company are saints driven by purely altruistic intent.
History shows that the opposite is overwhealming the case. Customers
wouldn't be offering your company money for a type-3 driver by any chance
would they?

c) one of the main reasons that people choose to program in Java is
because of its cross-platform binary abilities. Proposing changes which
undermine that ability are unlikely to win you (the company) many friends

d) there are some of us who through commercial experience don't want
either the potential instability or installation PITA of a type-3 driver.
ATM I can deploy PostgreSQL and the JDBC driver to my clients in the
knowledge that both have rock-solid stability. Do you think I would want
risk that?

So let's look at what the future may hold. I would guess that you're
already been told to to produce a type-3 driver for whoever. That's not an
issue for me. Where I start to worry is if you then decide to donate the
changed driver to the main source tree. Can the changes be merged in so
that a type-4 driver can still be built? Who knows? Are you going to
guarantee the continued existence and development of the type-4 driver or
will we all be forced to either use the type-3 or hack up our own type-4
drivers? And what about testing? Bugs in a type-3 driver can crash the JVM
so a very high level of stress testing will be required, probably on
multiple platforms. Are Red Hat going to make resources available for the
required level of testing? For years to come?

--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants |
http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+---------------------------------------------+

On Sat, Sep 13, 2003 at 05:28:03PM +0100, Paul Thomas wrote:
> On 13/09/2003 00:53 Tom Lane wrote:
>
> >You got up on the wrong side of the bed today? What's platform-specific
> >about Unix sockets?
>
> Well, Sun must regard them as pretty platform-specific as they're not part
> of the Java spec. In practice there's another issue. Its called binary
> compability. PostgreSQL users currently have the luxury of a type-4 (i.e.,
> pure Java) JDBC driver. So a driver can be built on a Linux box (for
> example) and that binary will also run on Windows, Solaris... Unix sockets
> would have to be accessed though JNI thus making the driver a type-3
> driver. Kiss goodbye to binary portability. And forget running the driver
> on Windows without (I would imagine) cygwin installed - and that would
> re-map to tcp/ip sockets "pretending" to be unix sockets - can't see much
> advantage in that one. Forget using JDBC from applets to as that requires
> a type-4 driver. Not that I would imagine that there are many people doing
> JDBC from applets but the ability is there ATM. That kind of portability I
> live without!

It's entirely possible to do support for unix sockets in a way that only
requires the JNI piece (and, in fact, most of the support classes) if you
actually *want* support for unix sockets. You need one layer of indirection
so that the generic code can deal in terms of a "PgSocket" interface always,
then just have different implementations that are loaded dynamically by name
based on the URL's scheme; if the load fails because of a
ClassNotFoundException or UnsatisfiedLinkError (because the AF_UNIX support
classes or JNI library are not available) you just don't support that URL
scheme.

So you can still distribute a generic type-4 driver with a note that says
"if you want AF_UNIX support, you need to make an implementation of these
classes available to the driver, e.g. by installing this piece of
JNI-supported code available at ..".

Would this satisfy your objections?

Actually, my real concern is this bit (from the GNU Classpath docs):

Linking this library statically or dynamically with other modules is making
a combined work based on this library. Thus, the terms and conditions of the
GNU General Public License cover the whole combination.

This would seem to make it hard to build & distribute a version of the
driver that built against the AF_UNIX code that's "derived from GNU
classpath" without invoking the GPL on the whole driver, even with the sort
of indirection I described above. We'd need a generic interface for AF_UNIX
sockets to build against, where one implementation was the
GNU-classpath-derived code, plus a search mechanism etc .. basically
reproduce much of the framework that java.net provides for socket
implementations.

-O

On Sat, Sep 13, 2003 at 05:28:03PM +0100, Paul Thomas wrote:

> >> Get real. If Red Hat want to improve the JDBC driver, the ability to
> >> properly use server side prepared statements from a JDBC connection
> >pool
> >> would give a massively bigger performance gain that anything you
> >possibly
> >> ever get between tcp/ip and unix sockets.
> >
> >Deepak did not state or imply that the motivation for this was
> >performance.
> >Actually, it's security: lots of people prefer to run their PG servers
> >with no open TCP ports at all. So it would be good if JDBC could talk
> >to such a server.
>
> You can hide the port from the outside world with a firewall and configure
> PostgreSQL to only accept tcp/ip connections for 127.0.0.1. And if packet
> sniffing on the loopback interface is a concern, is SSL not secure enough?
> Having said that, I'm not sure if the JDBC driver supports SSL ATM but
> even without it the security argument (as opposed to a dogmatic policy
> stance) looks very weak to me which is why I initially discounted it.

The current driver does support SSL. I'm not sure what certificate
management is like under this setup, but from past SSL experiences it's
going to be "interesting".

However, the simple solution to "I don't want the outside world to see the
server" is "don't listen on TCP/IP, then". Firewalls and tweaking
postgresql's host-based ACLs would work .. if configured and maintained
correctly .. but they are hardly the simplest solution and are more likely
to go wrong.

Also user authentication becomes interesting if you want to do access
control based on the local user's identity (quite likely when you're running
the client on the same machine as the server). You're going to have to run
an ident server at a minimum (more stuff to configure, firewall, and
maintain, and another point of failure as the DB relies on it). Unix sockets
can use SCM_CREDENTIALS to pass user information in a much simpler way. And
you can set filesystem-based (user/group) permissions on a unix socket,
something you can't do with a TCP/IP listener.

-O

On 14/09/2003 01:05 Oliver Jowett wrote:
> [snip]
> It's entirely possible to do support for unix sockets in a way that only
> requires the JNI piece (and, in fact, most of the support classes) if you
> actually *want* support for unix sockets. You need one layer of
> indirection
> so that the generic code can deal in terms of a "PgSocket" interface
> always,
> then just have different implementations that are loaded dynamically by
> name
> based on the URL's scheme; if the load fails because of a
> ClassNotFoundException or UnsatisfiedLinkError (because the AF_UNIX
> support
> classes or JNI library are not available) you just don't support that URL
> scheme.
>
> So you can still distribute a generic type-4 driver with a note that says
> "if you want AF_UNIX support, you need to make an implementation of these
> classes available to the driver, e.g. by installing this piece of
> JNI-supported code available at ..".
>
> Would this satisfy your objections?

To a certain extent. I'd have to see the actual implementation though. Of
course, by that point it would be a done deal :(

>
> Actually, my real concern is this bit (from the GNU Classpath docs):
>
> Linking this library statically or dynamically with other modules is
> making
> a combined work based on this library. Thus, the terms and conditions of
> the
> GNU General Public License cover the whole combination.
>
> This would seem to make it hard to build & distribute a version of the
> driver that built against the AF_UNIX code that's "derived from GNU
> classpath" without invoking the GPL on the whole driver, even with the
> sort
> of indirection I described above. We'd need a generic interface for
> AF_UNIX
> sockets to build against, where one implementation was the
> GNU-classpath-derived code, plus a search mechanism etc .. basically
> reproduce much of the framework that java.net provides for socket
> implementations.

Just when you thought it was safe to go back in the water: der-dum,
der-dum, here comes the GPL. And it's an issue that I have to be very
careful of. Hopefully the committers will take a long, hard look at this
before accepting the patch.

--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants |
http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+---------------------------------------------+