I have addressed these issues in my final patch. One other change I did
was change the host name comparison to case insensitive (Apache and TCP
Wrappers do the same).
I'm planning to work on a wildcard mechanism soon. After that the issue
of which way the host resolution should work will have an
On tis, 2010-10-12 at 17:03 -0400, Tom Lane wrote:
> Oh, I had an idea for a small improvement to this. It doesn't seem
> unlikely that pg_hba.conf could contain multiple entries with the same
> host name (but, presumably, different user and/or database names). As
> this is coded, you'll do a for
Peter Eisentraut writes:
>> Hopefully final patch, which addresses the above issues, adds some
>> documentation enhancements, and the possibility to quote host names (in
>> case someone wants to have a host named "samehost").
Oh, I had an idea for a small improvement to this. It doesn't seem
unl
Peter Eisentraut writes:
> Hopefully final patch, which addresses the above issues, adds some
> documentation enhancements, and the possibility to quote host names (in
> case someone wants to have a host named "samehost").
A few minor gripes:
> + If a host name is specified (anything that
On tis, 2010-10-12 at 10:11 +0900, KaiGai Kohei wrote:
> Is it really necessary to check reverse dns entries?
This has been extensively discussed in this thread.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On mån, 2010-10-11 at 21:34 +0300, Peter Eisentraut wrote:
> > * Why getnameinfo() in the fallback loop?
>
> I checked through my git history; this was actually a leftover from
> some
> debugging code. I'll remove it.
>
> > * Slash ('/') after the hostname
> >
> > At the parse_hba_line(), the p
(2010/10/12 3:34), Peter Eisentraut wrote:
> On tor, 2010-10-07 at 12:45 +0900, KaiGai Kohei wrote:
>> * The logic is still unclear for me.
>>
>> The check_hostname() immediately returns with false, if the resolved
>> remote hostname is NOT matched with the hostname described in pg_hba.conf.
>
>>
On tor, 2010-10-07 at 12:45 +0900, KaiGai Kohei wrote:
> * The logic is still unclear for me.
>
> The check_hostname() immediately returns with false, if the resolved
> remote hostname is NOT matched with the hostname described in pg_hba.conf.
> If the resolved hostname is matched with the hostna
On tis, 2010-10-05 at 22:28 -0400, Joachim Wieland wrote:
> This is exactly what I am seeing here. However contrary to your case
> the
> patch makes it even worse on my side. With the patch compiled in and a
> pg_hba.conf entry of "localhost", I cannot connect anymore to "-h
> localhost", I get "no
(2010/10/06 10:21), KaiGai Kohei wrote:
> I'll check the patch for more details, please wait for a few days.
I could find out some matters in this patch, independent from the
discussion of localhost. (About pg_hba.conf.sample, I'm sorry for
the missuggestion. Please fix up it according to Tom's co
On Wed, Oct 6, 2010 at 6:21 AM, Magnus Hagander wrote:
> It's not common, but i've certainly come across a number of virtual
> machines where localhost resolves (through /etc/hosts) to the machines
> "real" IP rather than 127.0.01, because 127.0.0.1 simply doesn't
> exist.
It's perfectly fine for
On 10/06/2010 09:49 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
That appears to me to be a broken (non RFC compliant) VM setup.
However, maybe what this is telling us is we need to expose the setting?
Or perhaps better, try 127.0.0.1, ::1, localhost, in that order.
Yeah, I
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> That appears to me to be a broken (non RFC compliant) VM setup.
> However, maybe what this is telling us is we need to expose the setting?
> Or perhaps better, try 127.0.0.1, ::1, localhost, in that order.
Yeah, I'd be happier if we exposed it, to be honest
On Wed, Oct 6, 2010 at 15:34, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Oct 6, 2010 at 15:16, Tom Lane wrote:
>>> However, the usage in pgstat.c is hard-wired, meaning that if you
>>> have a configuration where "localhost" doesn't resolve correctly
>>> for whatever reason, there's no
Magnus Hagander writes:
> On Wed, Oct 6, 2010 at 15:16, Tom Lane wrote:
>> However, the usage in pgstat.c is hard-wired, meaning that if you
>> have a configuration where "localhost" doesn't resolve correctly
>> for whatever reason, there's no simple recourse to get the stats
>> collector working
On Wed, Oct 6, 2010 at 15:16, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 10/06/2010 04:05 AM, Peter Eisentraut wrote:
>>> On tis, 2010-10-05 at 22:17 -0400, Tom Lane wrote:
So far as I can find, there is *no* standard
mandating that localhost means the loopback address.
>
>>> Should
Andrew Dunstan writes:
> On 10/06/2010 04:05 AM, Peter Eisentraut wrote:
>> On tis, 2010-10-05 at 22:17 -0400, Tom Lane wrote:
>>> So far as I can find, there is *no* standard
>>> mandating that localhost means the loopback address.
>> Should we then change pgstat.c to use IP addresses instead of
Peter Eisentraut writes:
> On tis, 2010-10-05 at 22:17 -0400, Tom Lane wrote:
>> So far as I can find, there is *no* standard
>> mandating that localhost means the loopback address.
> Should we then change pgstat.c to use IP addresses instead of hardcoding
> "localhost"?
Hm, perhaps so.
On 10/06/2010 04:05 AM, Peter Eisentraut wrote:
On tis, 2010-10-05 at 22:17 -0400, Tom Lane wrote:
So far as I can find, there is *no* standard
mandating that localhost means the loopback address.
Should we then change pgstat.c to use IP addresses instead of hardcoding
"localhost"?
I under
On tis, 2010-10-05 at 22:17 -0400, Tom Lane wrote:
> So far as I can find, there is *no* standard
> mandating that localhost means the loopback address.
Should we then change pgstat.c to use IP addresses instead of hardcoding
"localhost"?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On Tue, Oct 5, 2010 at 3:41 PM, Peter Eisentraut wrote:
> The reason why I think this is semi-important and not just cosmetic is
> that (for some reason that is not entirely clear to me) clients
> connecting to localhost end up appearing to the server as ::1 on a lot
> of machines I use which are
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Between these issues and the speed concern, I don't think that we should
> change this.
+1.
Stephen
signature.asc
Description: Digital signature
KaiGai Kohei writes:
>> Note that we already default listen_addresses to 'localhost', so it
>> would only make sense to have pg_hba.conf behave the same by default.
>> To pick up on your argument, we effectively *do* make assumptions
>> about /etc/hosts now, and this change would remove them.
>>
(2010/10/06 4:41), Peter Eisentraut wrote:
> On tis, 2010-10-05 at 12:35 +0900, KaiGai Kohei wrote:
>> It seems to me this patch has been left for a long time, although it tries
>> to provide a useful functionality.
>>
>> In the previous discussion, several issues were pointed out.
>>
>> * Case han
On tis, 2010-10-05 at 12:35 +0900, KaiGai Kohei wrote:
> It seems to me this patch has been left for a long time, although it tries
> to provide a useful functionality.
>
> In the previous discussion, several issues were pointed out.
>
> * Case handling when an IP-address has multiple hostnames.
It seems to me this patch has been left for a long time, although it tries
to provide a useful functionality.
In the previous discussion, several issues were pointed out.
* Case handling when an IP-address has multiple hostnames.
Steve Atkins noticed getaddrinfo() does not have capability to han
On Aug 10, 2010, at 8:23 AM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> On mån, 2010-08-09 at 13:56 -0500, Kevin Grittner wrote:
>>> Some IP addresses have several host names, including in reverse
>>> lookup; how is that handled?
>>
>> This is not possible, or at least
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> It's hardly nonsense to have multiple names on a machine. While we
> usually avoid having multiple reverse lookup names, we have many
> in-house web applications and we neither want users to access them
> by IP address or have to worry about
* Aidan Van Dyk (ai...@highrise.ca) wrote:
> The PTR query is a means to get the "hostname" to check against, so you
> d'nt have to pre-cache all thos possible results of all the hostnames.
> Pre-caching all the hostnames in pg_hba.conf is madness. How long do
> you cache them for? or do send out
* Peter Eisentraut (pete...@gmx.net) wrote:
> On mån, 2010-08-09 at 13:56 -0500, Kevin Grittner wrote:
> > Some IP addresses have several host names, including in reverse
> > lookup; how is that handled?
>
> This is not possible, or at least the C library APIs don't expose it.
> Compare the getnam
Peter Eisentraut writes:
> On tis, 2010-08-10 at 10:39 -0400, Tom Lane wrote:
>> I was about to complain about that same thing. ISTM the logic ought
>> to be that you do a forward DNS lookup on the name presented in
>> pg_hba.conf, and if any of the returned IP addresses match the
>> connection's
Peter Eisentraut writes:
> On tis, 2010-08-10 at 09:18 -0500, Kevin Grittner wrote:
>> Why can't a forward lookup which matches the requesting IP be considered
>> sufficient?
> For one thing, because people might like to add wildcard support. So I
> might be able to say
> host all all appserv
On tis, 2010-08-10 at 10:39 -0400, Tom Lane wrote:
> I was about to complain about that same thing. ISTM the logic ought
> to be that you do a forward DNS lookup on the name presented in
> pg_hba.conf, and if any of the returned IP addresses match the
> connection's remote IP address, then you hav
* Tom Lane [100810 10:39]:
> I was about to complain about that same thing. ISTM the logic ought
> to be that you do a forward DNS lookup on the name presented in
> pg_hba.conf, and if any of the returned IP addresses match the
> connection's remote IP address, then you have a match. This busin
"Kevin Grittner" writes:
> Without the logic to ensure that the hostname matches the reverse
> lookup, this might be useful for us. With that logic it is useless
> for us. I'm wondering how much you gain by having it in there. Why
> can't a forward lookup which matches the requesting IP be cons
On tis, 2010-08-10 at 09:18 -0500, Kevin Grittner wrote:
> Without the logic to ensure that the hostname matches the reverse
> lookup, this might be useful for us. With that logic it is useless
> for us. I'm wondering how much you gain by having it in there. Why
> can't a forward lookup which ma
On tis, 2010-08-10 at 10:11 -0400, Robert Haas wrote:
> These days, I think it's more common the other way around: one IP
> address, and many host names.
Yes, that setup is very common, but it's actually only an illusion that
DNS creates. The actual machine still has only one host name and some
I
Peter Eisentraut wrote:
> Yeah, you can configure all kinds of nonsense and sometimes even
> get away with it, but the basic assumption throughout is that a
> system has one host name and between 1 and many IP addresses.
It's hardly nonsense to have multiple names on a machine. While we
usual
On Tue, Aug 10, 2010 at 10:05 AM, Peter Eisentraut wrote:
> On tis, 2010-08-10 at 07:32 -0500, Kevin Grittner wrote:
>> http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records
>
> Yeah, you can configure all kinds of nonsense and sometimes even get
> away with it, but the basic as
On tis, 2010-08-10 at 07:32 -0500, Kevin Grittner wrote:
> http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records
Yeah, you can configure all kinds of nonsense and sometimes even get
away with it, but the basic assumption throughout is that a system has
one host name and between
Peter Eisentraut wrote:
> On mån, 2010-08-09 at 13:56 -0500, Kevin Grittner wrote:
>> Peter Eisentraut wrote:
>>> is reverse looked up, which results in a host name.
>>
>> Some IP addresses have several host names, including in reverse
>> lookup; how is that handled?
>
> This is not possible,
On mån, 2010-08-09 at 15:25 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Here is a patch for host name support in pg_hba.conf.
>
> My recollection is that the previous discussions got stuck on the cost
> of doing DNS lookups for every connect; and the obvious solution of
> trying to cach
On mån, 2010-08-09 at 23:01 +0200, Kristian Larsson wrote:
> In which order are things evaluated? What if I only include IP
> addresses in my pg_hba, will it still cost me a DNS lookup or
> two?
No, if you don't use this feature, it won't cost you anything.
--
Sent via pgsql-hackers mailing lis
On mån, 2010-08-09 at 13:56 -0500, Kevin Grittner wrote:
> Peter Eisentraut wrote:
>
> > The client's IP address (known from the kernel)
>
> Some machines have several IP addresses; how is that handled?
A connection comes in over exactly one address.
> > is reverse looked up, which results
On mån, 2010-08-09 at 15:05 -0400, Robert Haas wrote:
> -1 from me, on this part. I think we should be trying to eliminate
> any dependencies we have on how localhost resolves, and we certainly
> should not add more.
Maybe this is something that distributors could add if they have more
knowledge
On Mon, Aug 09, 2010 at 03:25:23PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Here is a patch for host name support in pg_hba.conf.
>
> My recollection is that the previous discussions got stuck on the cost
> of doing DNS lookups for every connect; and the obvious solution of
> trying
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> > The client's IP address (known from the kernel)
>
> Some machines have several IP addresses; how is that handled?
Sounds like he already described it, or I read it wrong. The fact that
some machines have several IP addresses hardly matte
Peter Eisentraut writes:
> Here is a patch for host name support in pg_hba.conf.
My recollection is that the previous discussions got stuck on the cost
of doing DNS lookups for every connect; and the obvious solution of
trying to cache the names was shot down on the basis of not knowing when
to f
On Mon, Aug 9, 2010 at 2:47 PM, Peter Eisentraut wrote:
> Here is a patch for host name support in pg_hba.conf. I have reviewed
> various past threads about this, and there appeared to have been a 50/50
> split of for and against reverse lookup. I went with the reverse
> lookup, because
>
> 0) I
On 9 August 2010 19:47, Peter Eisentraut wrote:
> Here is a patch for host name support in pg_hba.conf. I have reviewed
> various past threads about this, and there appeared to have been a 50/50
> split of for and against reverse lookup. I went with the reverse
> lookup, because
>
> 0) I like it
Peter Eisentraut wrote:
> The client's IP address (known from the kernel)
Some machines have several IP addresses; how is that handled?
> is reverse looked up, which results in a host name.
Some IP addresses have several host names, including in reverse
lookup; how is that handled?
-Kevi
Here is a patch for host name support in pg_hba.conf. I have reviewed
various past threads about this, and there appeared to have been a 50/50
split of for and against reverse lookup. I went with the reverse
lookup, because
0) I like it.
1) It is more secure.
2) It allows extending it to wildc
52 matches
Mail list logo
