Thread: 7.4devel auth failed
Trying to connect from pgadmin2, I get the message "no pg_hba.conf entry for ..." I found that the ip address matching with rangeSockAdr in line 651 in hba.c fails. I get access if I set ipaddr/mask to 0.0.0.0/0.0.0.0 in pg_hba.conf.
That's strange. I just tested it here, and it worked. I have IPv6 code
enabled. but no IPv6 in my kernel, so there are just IPv4 connections.
Can you peek in this funciton and see where it is failing:intrangeSockAddrAF_INET(const SockAddr *addr, const SockAddr
*netaddr, const SockAddr *netmask){ if (addr->sa.sa_family != AF_INET ||
netaddr->sa.sa_family!= AF_INET || netmask->sa.sa_family != AF_INET) return 0; if
(((addr->in.sin_addr.s_addr^ netaddr->in.sin_addr.s_addr) & netmask->in.sin_addr.s_addr) == 0) return 1;
else return 0;}
That is the IPv4 function.
---------------------------------------------------------------------------
Andreas Pflug wrote:
> Trying to connect from pgadmin2, I get the message
> "no pg_hba.conf entry for ..."
>
> I found that the ip address matching with rangeSockAdr in line 651 in
> hba.c fails.
>
> I get access if I set ipaddr/mask to 0.0.0.0/0.0.0.0 in pg_hba.conf.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
Ok Bruce,
I found out what's happening.
I'm running a Suse 8.1 2.4.19 standard kernel which has IPV6 enabled by
default. When connecting locally over IP (pgaccess), hba is checked
against IPV6 patterns in pg_hba.conf.
My pgadmin2 machine will connect with an IP4-to-6 mapped address of
0:ffff:c0a80002 (192.168.0.2), which convSockAddr6to4 will convert to
dst->in.sin_addr.s_addr=0xc0a80002. On the other side, SockAddr_pton
will convert my 192.168.0.0/255.255.255.0 entry to a8c0/ffffff, and
consequently rangeSockAddr will fail.
If your kernel isn't V6 enabled, the incoming socket will be AF_INET,
and no conversion is done, that's why you don't get the problem.
To fix this, the [12]..[15] indices need to be reversed (for Intel).
This might be machine specific... Maybe for all big-endian machines the
current code is ok, and needs reversal for little-endian processors.
I wonder if the following is completely portable, could be:
dst->in.sin_addr.s_addr = *(in_addr_t*)(src->in4.sin6_addr.s6_addr+12);
Regards,
Andreas
PS Your mail host candle.pha.pa.us rejected this mail as spam?!?
Bruce Momjian wrote:
>That's strange. I just tested it here, and it worked. I have IPv6 code
>enabled. but no IPv6 in my kernel, so there are just IPv4 connections.
>
>Can you peek in this funciton and see where it is failing:
>
> int
> rangeSockAddrAF_INET(const SockAddr *addr, const SockAddr *netaddr,
> const SockAddr *netmask)
> {
> if (addr->sa.sa_family != AF_INET ||
> netaddr->sa.sa_family != AF_INET ||
> netmask->sa.sa_family != AF_INET)
> return 0;
> if (((addr->in.sin_addr.s_addr ^ netaddr->in.sin_addr.s_addr) &
> netmask->in.sin_addr.s_addr) == 0)
> return 1;
> else
> return 0;
> }
>
>That is the IPv4 function.
>
>
>
>
I am confused about using only the last few bytes. Does this
adjustment of IP addresses help:voidconvSockAddr6to4(const SockAddr *src, SockAddr *dst){ char
addr_str[INET6_ADDRSTRLEN]; dst->in.sin_family = AF_INET; dst->in.sin_port = src->in6.sin6_port;
dst->in.sin_addr.s_addr= (src->in6.sin6_addr.s6_addr[15]) + (src->in6.sin6_addr.s6_addr[14] << 8)
+(src->in6.sin6_addr.s6_addr[13] << 16) + (src->in6.sin6_addr.s6_addr[12] << 24); SockAddr_ntop(src,
addr_str,INET6_ADDRSTRLEN, 0);}
Can you supply a patch?
FYI, I do have IPv6 enabled libraries, but not in my kernel.
> PS Your mail host candle.pha.pa.us rejected this mail as spam?!?
I have whitelisted web.de. I received spam from them last month, and
didn't know if they were legit or just a spamhouse. Unfortunately, I
don't check each one I blacklist.
---------------------------------------------------------------------------
Andreas Pflug wrote:
> Ok Bruce,
>
> I found out what's happening.
> I'm running a Suse 8.1 2.4.19 standard kernel which has IPV6 enabled by
> default. When connecting locally over IP (pgaccess), hba is checked
> against IPV6 patterns in pg_hba.conf.
> My pgadmin2 machine will connect with an IP4-to-6 mapped address of
> 0:ffff:c0a80002 (192.168.0.2), which convSockAddr6to4 will convert to
> dst->in.sin_addr.s_addr=0xc0a80002. On the other side, SockAddr_pton
> will convert my 192.168.0.0/255.255.255.0 entry to a8c0/ffffff, and
> consequently rangeSockAddr will fail.
>
> If your kernel isn't V6 enabled, the incoming socket will be AF_INET,
> and no conversion is done, that's why you don't get the problem.
> To fix this, the [12]..[15] indices need to be reversed (for Intel).
> This might be machine specific... Maybe for all big-endian machines the
> current code is ok, and needs reversal for little-endian processors.
> I wonder if the following is completely portable, could be:
> dst->in.sin_addr.s_addr = *(in_addr_t*)(src->in4.sin6_addr.s6_addr+12);
>
> Regards,
> Andreas
>
> PS Your mail host candle.pha.pa.us rejected this mail as spam?!?
>
>
>
> Bruce Momjian wrote:
>
> >That's strange. I just tested it here, and it worked. I have IPv6 code
> >enabled. but no IPv6 in my kernel, so there are just IPv4 connections.
> >
> >Can you peek in this funciton and see where it is failing:
> >
> > int
> > rangeSockAddrAF_INET(const SockAddr *addr, const SockAddr *netaddr,
> > const SockAddr *netmask)
> > {
> > if (addr->sa.sa_family != AF_INET ||
> > netaddr->sa.sa_family != AF_INET ||
> > netmask->sa.sa_family != AF_INET)
> > return 0;
> > if (((addr->in.sin_addr.s_addr ^ netaddr->in.sin_addr.s_addr) &
> > netmask->in.sin_addr.s_addr) == 0)
> > return 1;
> > else
> > return 0;
> > }
> >
> >That is the IPv4 function.
> >
> >
> >
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
On Tue, Mar 25, 2003 at 12:28:43PM +0100, Andreas Pflug wrote: > Ok Bruce, > > I found out what's happening. > I'm running a Suse 8.1 2.4.19 standard kernel which has IPV6 enabled by > default. When connecting locally over IP (pgaccess), hba is checked > against IPV6 patterns in pg_hba.conf. > My pgadmin2 machine will connect with an IP4-to-6 mapped address of > 0:ffff:c0a80002 (192.168.0.2), which convSockAddr6to4 will convert to You mean ::ffff:c0a8:0002 or ::ffff:192.168.0.2? (::ffff:c0a80002 is not valid.) > dst->in.sin_addr.s_addr=0xc0a80002. Which is the right value for it. > On the other side, SockAddr_pton > will convert my 192.168.0.0/255.255.255.0 entry to a8c0/ffffff, and > consequently rangeSockAddr will fail. Something is wrong here. It somehow converted them to host byte order where it shouldn't. SockAddr_pton() basicly does: return inet_pton(AF_INET, src, &sa->in.sin_addr); Which should return the data in network byte order. > If your kernel isn't V6 enabled, the incoming socket will be AF_INET, > and no conversion is done, that's why you don't get the problem. > To fix this, the [12]..[15] indices need to be reversed (for Intel). > This might be machine specific... Maybe for all big-endian machines the > current code is ok, and needs reversal for little-endian processors. > I wonder if the following is completely portable, could be: > dst->in.sin_addr.s_addr = *(in_addr_t*)(src->in4.sin6_addr.s6_addr+12); Where should you place that? I can't see anything wrong with the code as it is now. I think I even tested it for ipv4 and it worked for me, so I have no idea what's wrong. I've made alot of changes to the current code but it's not finnished yet, and really have no time atm. It currently only compiles on a host that has ipv6 in libc. It shouldn't be too much work to get it to compile on a host without ipv4. Kurt
Shouldn't the fix involve an appropriate use of ntohl or htonl,
instead of ad-hoc shifting?
regards, tom lane
On Wed, Mar 26, 2003 at 12:36:00AM +0100, Andreas Pflug wrote: > Kurt, > > for my opinion, ConvSockAddr6to4 works wrong. The resulting ip address > looks good for the eye, but only if printed as an integer which will > interpret it little-endian (host byte order). Oops, I didn't see that one. convSockAddr6to4() is obviously wrong. There is where it gets converted to host order where it shouldn't. What is that SockAddr_ntop() doing there anyway? Maybe the inteded code was a combination for SockAddr_ntop() and SockAddr_pton()? Kurt
Bruce Momjian writes: > I have whitelisted web.de. I received spam from them last month, and > didn't know if they were legit or just a spamhouse. Unfortunately, I > don't check each one I blacklist. Maybe you should. You've blacklisted me, too. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I have whitelisted web.de. I received spam from them last month, and > > didn't know if they were legit or just a spamhouse. Unfortunately, I > > don't check each one I blacklist. > > Maybe you should. You've blacklisted me, too. OK, fixed. You know, I started getting email that is clearly grabbing from our web page, titled "dpage, ...". Seems that might be how your address got in. I will look at the next one and see if they appear to be coming from the original hosts. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Andreas Pflug <Andreas.Pflug@web.de> writes:
> If your kernel isn't V6 enabled, the incoming socket will be AF_INET,
> and no conversion is done, that's why you don't get the problem.
> To fix this, the [12]..[15] indices need to be reversed (for Intel).
I've applied a patch to fix this, but can't try it out here for lack of
any IPv6 infrastructure ... please check it.
regards, tom lane
Looks like Tom just checked a fix into CVS for your reported problem.
Would you please test it?
---------------------------------------------------------------------------
Andreas Pflug wrote:
> Ok Bruce,
>
> I found out what's happening.
> I'm running a Suse 8.1 2.4.19 standard kernel which has IPV6 enabled by
> default. When connecting locally over IP (pgaccess), hba is checked
> against IPV6 patterns in pg_hba.conf.
> My pgadmin2 machine will connect with an IP4-to-6 mapped address of
> 0:ffff:c0a80002 (192.168.0.2), which convSockAddr6to4 will convert to
> dst->in.sin_addr.s_addr=0xc0a80002. On the other side, SockAddr_pton
> will convert my 192.168.0.0/255.255.255.0 entry to a8c0/ffffff, and
> consequently rangeSockAddr will fail.
>
> If your kernel isn't V6 enabled, the incoming socket will be AF_INET,
> and no conversion is done, that's why you don't get the problem.
> To fix this, the [12]..[15] indices need to be reversed (for Intel).
> This might be machine specific... Maybe for all big-endian machines the
> current code is ok, and needs reversal for little-endian processors.
> I wonder if the following is completely portable, could be:
> dst->in.sin_addr.s_addr = *(in_addr_t*)(src->in4.sin6_addr.s6_addr+12);
>
> Regards,
> Andreas
>
> PS Your mail host candle.pha.pa.us rejected this mail as spam?!?
>
>
>
> Bruce Momjian wrote:
>
> >That's strange. I just tested it here, and it worked. I have IPv6 code
> >enabled. but no IPv6 in my kernel, so there are just IPv4 connections.
> >
> >Can you peek in this funciton and see where it is failing:
> >
> > int
> > rangeSockAddrAF_INET(const SockAddr *addr, const SockAddr *netaddr,
> > const SockAddr *netmask)
> > {
> > if (addr->sa.sa_family != AF_INET ||
> > netaddr->sa.sa_family != AF_INET ||
> > netmask->sa.sa_family != AF_INET)
> > return 0;
> > if (((addr->in.sin_addr.s_addr ^ netaddr->in.sin_addr.s_addr) &
> > netmask->in.sin_addr.s_addr) == 0)
> > return 1;
> > else
> > return 0;
> > }
> >
> >That is the IPv4 function.
> >
> >
> >
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
Tom Lane wrote: >I've applied a patch to fix this, but can't try it out here for lack of >any IPv6 infrastructure ... please check it. > > regards, tom lane > > > I tried it, and it works. Regards, Andreas