Why IDENT doesn't work with JDBC

I'm kind of surprised that I don't see any posts about this issue on
this list. Am I the only one using this combination?

I've created a Bugzilla entry for Red Hat's authd about this problem:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139956

Other IDENT protocol daemons seem to suffer from the same problem.

A temporary workaround is to set the java.net.preferIPv4Stack system
property to true.

--
========================================================================
Ian Pilcher i(dot)pilcher(at)comcast(dot)net
========================================================================

Ian Pilcher wrote:
> I'm kind of surprised that I don't see any posts about this issue on
> this list. Am I the only one using this combination?

I'd guess that both IPV6 and authentication via ident-over-TCP are not
particularly common.

-O

Oliver Jowett wrote:
>
> I'd guess that both IPV6 and authentication via ident-over-TCP are not
> particularly common.
>

Did you read the bug? Java 1.4.2+ *always* uses IPv6 on Linux, unless
you tell it not to. AFAIK, all recent Linux distributions ship with
IPv6 turned on, so it's present even if there isn't an external IPv6
network.

As far as ident-over-TCP, it's the only way to do it with JDBC. For my
money, it beats the heck out of storing your database password in your
web application!

--
========================================================================
Ian Pilcher i(dot)pilcher(at)comcast(dot)net
========================================================================

Ian Pilcher wrote:
> Oliver Jowett wrote:
>
>>
>> I'd guess that both IPV6 and authentication via ident-over-TCP are not
>> particularly common.
>
> Did you read the bug?

Yes, I did.

> Java 1.4.2+ *always* uses IPv6 on Linux, unless
> you tell it not to.

Or unless IPv6 kernel support is not present.

> AFAIK, all recent Linux distributions ship with
> IPv6 turned on, so it's present even if there isn't an external IPv6
> network.

None of the Linux boxes here have IPv6 enabled. If you're compiling a
custom kernel, and you don't have a physical IPv6 network, why would you
enable IPv6?

> As far as ident-over-TCP, it's the only way to do it with JDBC. For my
> money, it beats the heck out of storing your database password in your
> web application!

It's not particularly useful if you have anything other than a N:1
mapping between system users and database users, though. The setups I
have seen either use localhost trust, or md5 + password on the client
app. ident doesn't seem too common.

So you need all of: recent JVM, IPv6-enabled kernel, buggy ident server,
and pg_hba.conf that uses 'ident'. It's not too surprising that noone
else appears to have hit this combination before. To answer your
original question: yes, apparently you *are* the only one using that
combination.

Anyway, thanks for the report and workaround, it's good to get that
information into the archives. There doesn't seem to be anything that
postgresql or the JDBC driver can do about the problem, though.

-O

Oliver Jowett wrote:
> Ian Pilcher wrote:
>> Did you read the bug?
> Yes, I did.

My appologies if that sounded a little short.

> Anyway, thanks for the report and workaround, it's good to get that
> information into the archives. There doesn't seem to be anything that
> postgresql or the JDBC driver can do about the problem, though.

There might be a way for the driver to force an IPv4 connection, even
when java.net.preferIPv4Stack isn't set. It doesn't seem worth the
effort to me, though.

Something I find slightly interesting is the idea of having postgresql
do its own parsing of /proc/net/tcp* (or netstat output) when it gets a
connection request over the loopback adapter. This would obviate the
need for a seperate IDENT daemon (with all of its security problems) in
the loopback case.

In the short term, however, the answer is definitely to get the IDENT
daemon authors of the world to fix their programs. (I am somewhat
concerned that Red Hat will come back with a "working as designed"
answer.)

--
========================================================================
Ian Pilcher i(dot)pilcher(at)comcast(dot)net
========================================================================