Обсуждение: 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.pilcher@comcast.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.pilcher@comcast.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.pilcher@comcast.net ========================================================================