Christopher Head wrote:
> On Wed, 14 Jul 2010 18:35:55 -0400
> Tom Lane wrote:
>
> > Bruce Momjian writes:
> > > Do the docs need any more updating?
> >
> > No doubt, but it's a bit premature to consider that while we're still
> > arguing whether the code needs to change more.
> >
> >
On Tue, 4 Jan 2011 19:42:38 -0500
Robert Haas wrote:
> Me, too. I reread the original discussion of this topic and I'm still
> a little fuzzy on it, but the issue that was under discussion seems to
> be what information we pass to external auth libraries like GSSAPI or
> Kerberos, given that we
On Sun, Dec 19, 2010 at 5:13 PM, Christopher Head wrote:
> On Wed, 14 Jul 2010 18:35:55 -0400
> Tom Lane wrote:
>
>> Bruce Momjian writes:
>> > Do the docs need any more updating?
>>
>> No doubt, but it's a bit premature to consider that while we're still
>> arguing whether the code needs to cha
On Wed, 14 Jul 2010 18:35:55 -0400
Tom Lane wrote:
> Bruce Momjian writes:
> > Do the docs need any more updating?
>
> No doubt, but it's a bit premature to consider that while we're still
> arguing whether the code needs to change more.
>
> regards, tom lane
>
Sorry to
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I suggest that we document hostaddr as being an auxiliary field that is
>> not intended to be the primary source of the host name, but merely saves
>> libpq from having to do a forward DNS lookup. In some cases it will
>> work to s
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I suggest that we document hostaddr as being an auxiliary field that is
> not intended to be the primary source of the host name, but merely saves
> libpq from having to do a forward DNS lookup. In some cases it will
> work to supply hostaddr without host,
Stephen Frost writes:
> Reviewing what's currently on developer.postgresql.org, here's what I
> think the docs would read and what the associated code behavior should
> be (which I think it's pretty close to already, but perhaps not
> entirely..):
I think this is overcomplicated and probably wron
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Perhaps I was being a bit overzealous in my last response, sorry about
> > that. If the point here is that people who are using hostaddr are in an
> > environment where DNS is non-functional or actively broken, then yes,
> > just
Bruce Momjian writes:
> Do the docs need any more updating?
No doubt, but it's a bit premature to consider that while we're still
arguing whether the code needs to change more.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make cha
Do the docs need any more updating?
---
Tom Lane wrote:
> Stephen Frost writes:
> > Perhaps I was being a bit overzealous in my last response, sorry about
> > that. If the point here is that people who are using hostaddr a
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Hm. That might happen to work for Kerberos, but it won't work for
> GSSAPI or SSPI --- in both those code paths we just push the host name
> literally into a constructed principal string. Not sure if we really
> want Kerberos to work differently from the m
Stephen Frost writes:
> Perhaps I was being a bit overzealous in my last response, sorry about
> that. If the point here is that people who are using hostaddr are in an
> environment where DNS is non-functional or actively broken, then yes,
> just bombing out would probably be fine.
Well, if you
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Uh, no, because hostaddr is (required to be) a numeric IP. The odds of
>> it being useful in this context seem negligible.
> Err, no, it'll work just fine- gethostbyname() will take the dotted-quad
> numeric IP and return the host
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Uh, no, because hostaddr is (required to be) a numeric IP. The odds of
> it being useful in this context seem negligible.
Perhaps I was being a bit overzealous in my last response, sorry about
that. If the point here is that people who are using hostaddr
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > krb5_sname_to_principal() will use the passed hostname for the second
> > component. If type is KRB5_NT_SRV_HST this name will be looked up with
> > gethostbyname(). If hostname is NULL, the local hostname will be
Stephen Frost writes:
> krb5_sname_to_principal() will use the passed hostname for the second
> component. If type is KRB5_NT_SRV_HST this name will be looked up with
> gethostbyname(). If hostname is NULL, the local hostname will be used.
> If we were passing in NULL before when
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I've never found a reason to use hostaddr, so I don't particularly care,
> > but it doesn't seem right to break Kerberos auth if you were only given
> > an IP address unless hostaddr's entire point is that it will prevent a
> > DNS
Stephen Frost writes:
> I've never found a reason to use hostaddr, so I don't particularly care,
> but it doesn't seem right to break Kerberos auth if you were only given
> an IP address unless hostaddr's entire point is that it will prevent a
> DNS lookup from happening, ever.
Well, given your d
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Yeah, but the code in fe-auth.c throws an error before the Kerberos
> libraries get a chance to do any such thing. I suppose that the
> documentation text was accurate when written, but that was a long time
> ago.
e, yeah, there are some issues with th
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> ... btw, the libpq documentation claims that
>>
>> If hostaddr is specified without host, the value for hostaddr
>> gives the remote address. When Kerberos is used, a reverse name
>> query occurs to obtain the host name for Kerbero
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> ... btw, the libpq documentation claims that
>
> If hostaddr is specified without host, the value for hostaddr
> gives the remote address. When Kerberos is used, a reverse name
> query occurs to obtain the host name for Kerberos.
>
> but
... btw, the libpq documentation claims that
If hostaddr is specified without host, the value for hostaddr
gives the remote address. When Kerberos is used, a reverse name
query occurs to obtain the host name for Kerberos.
but so far as I can see this is flat wrong. pg_krb
Magnus Hagander writes:
> On Wed, Jul 14, 2010 at 00:09, Tom Lane wrote:
>> "Christopher Head" writes:
>>> ... Unfortunately, as per line 536 of the file
>>> fe-secure.c in the PostgreSQL sources, if hostaddr is specified, SSL full
>>> verification just plain fails without trying at all. I suspe
On Wed, Jul 14, 2010 at 00:09, Tom Lane wrote:
> "Christopher Head" writes:
>> When establishing a connection to a PostgreSQL server using a connection
>> string, there are two parameters that can be provided to specify where to
>> connect to: "host" and "hostaddr". If both are provided, the docu
"Christopher Head" writes:
> When establishing a connection to a PostgreSQL server using a connection
> string, there are two parameters that can be provided to specify where to
> connect to: "host" and "hostaddr". If both are provided, the documentation
> states that "hostaddr" is used to actuall
The following bug has been logged online:
Bug reference: 5559
Logged by: Christopher Head
Email address: chris2...@hotmail.com
PostgreSQL version: 8.4.4
Operating system: Gentoo Linux i386, kernel 2.6.34
Description:Full SSL verification fails when hostaddr provided
D
26 matches
Mail list logo
