Tom Lane escribió:
> Robert Haas writes:
> > On Tue, Apr 20, 2010 at 7:13 PM, Tom Lane wrote:
> >> (You might want to look back at the archived discussions about how to
> >> avoid storing entries for temp tables in these catalogs; that poses
> >> many of the same issues.)
>
> > Do you happen to
Robert Haas writes:
> On Tue, Apr 20, 2010 at 7:13 PM, Tom Lane wrote:
>> (You might want to look back at the archived discussions about how to
>> avoid storing entries for temp tables in these catalogs; that poses
>> many of the same issues.)
> Do you happen to know what a good search term migh
On Tue, Apr 20, 2010 at 7:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> I suppose the problem here is that pg_attribute and pg_class are not
>> shared catalogs, so we can't read them without selecting a database.
>
> Among other things.
>
>> What about making a fake version of these relations t
Robert Haas writes:
> I suppose the problem here is that pg_attribute and pg_class are not
> shared catalogs, so we can't read them without selecting a database.
Among other things.
> What about making a fake version of these relations that includes only
> the shared catalogs?
Well, after you s
Robert Haas escribió:
> I suppose the problem here is that pg_attribute and pg_class are not
> shared catalogs, so we can't read them without selecting a database.
> What about making a fake version of these relations that includes only
> the shared catalogs?
Hmm, interesting. I wonder if someth
On Tue, Apr 20, 2010 at 5:51 PM, Robert Haas wrote:
> On Tue, Apr 20, 2010 at 5:02 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane wrote:
3. We'd have to nail pg_authid, pg_auth_members, and their indexes into
relcache, because relcache.c isn't
On Tue, Apr 20, 2010 at 5:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane wrote:
>>> 3. We'd have to nail pg_authid, pg_auth_members, and their indexes into
>>> relcache, because relcache.c isn't prepared to cope otherwise. I doubt
>>> this would affect
Alvaro Herrera writes:
> Tom Lane escribió:
>> 2. We don't have infrastructure that would allow access to out-of-line
>> toasted fields during startup. Rather than try to add such, I propose
>> removing pg_authid's toast table, with the consequence that rolpassword
>> cannot be long enough to req
Robert Haas writes:
> On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane wrote:
>> 3. We'd have to nail pg_authid, pg_auth_members, and their indexes into
>> relcache, because relcache.c isn't prepared to cope otherwise. I doubt
>> this would affect performance in any material way, but it would eat a
>>
On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane wrote:
> 1. We'd have to force an initdb because of a couple of small catalog
> changes. This doesn't seem like a showstopper at this phase of the
> release cycle, but it's slightly annoying. pg_migrator could be used
> if anyone's really in need of it.
Tom Lane escribió:
> 1. We'd have to force an initdb because of a couple of small catalog
> changes. This doesn't seem like a showstopper at this phase of the
> release cycle, but it's slightly annoying. pg_migrator could be used
> if anyone's really in need of it.
check
> 2. We don't have inf
I wrote:
> ... So we could solve both this and
> the original complaint in the thread if we can arrange for all
> authentication to be done on the basis of shared-catalog access under
> rules similar to what the AV launcher does with pg_database. At a
> minimum that will require marking the pg_aut
I wrote:
> Actually, while I'm looking at that code, a more immediate TODO is
> "fix walsender". Somebody has inserted an absolutely flight-of-fantasy
> code path into InitPostgres. (Hint: template1 can be dropped.
> ESPECIALLY when you're deliberately not taking any lock on it.)
Now that I look
Robert Haas writes:
> http://blog.metasploit.com/2010/02/postgres-fingerprinting.html
> Assuming the situation really is as described here, I am wondering if
> we should suppress the F, L, and R output in this and similar cases
> and back-patch it all the way back. This seems like it is entirely
On Mon, Apr 19, 2010 at 8:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 19, 2010 at 7:18 PM, Tom Lane wrote:
>>> Hmm. The AV launcher is only permitted to touch pg_database.
>
>> Perhaps we should add a TODO.
>
> Actually, while I'm looking at that code, a more immediate TODO is
>
Robert Haas writes:
> On Mon, Apr 19, 2010 at 7:18 PM, Tom Lane wrote:
>> Hmm. The AV launcher is only permitted to touch pg_database.
> Perhaps we should add a TODO.
Actually, while I'm looking at that code, a more immediate TODO is
"fix walsender". Somebody has inserted an absolutely flight
On Mon, Apr 19, 2010 at 7:18 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Robert Haas escribió:
>>> Would it be possible to set up a skeleton environment where we can
>>> access shared catalogs only and then decide on which database we're
>>> using later?
>
>> Eh? We already do that ... In fa
Alvaro Herrera writes:
> Robert Haas escribió:
>> Would it be possible to set up a skeleton environment where we can
>> access shared catalogs only and then decide on which database we're
>> using later?
> Eh? We already do that ... In fact the autovac launcher is always
> connected to shared ca
Simon Riggs writes:
> With code as currently, yes, though I see that there is a way to do
> this.
> Rules that have an "all" in the database field of the hba can be applied
> prior to attempting to select the database, as long as the "all" rule is
> above any database-specific rules.
Well, that
On Mon, 2010-04-19 at 17:52 -0400, Robert Haas wrote:
> On Mon, Apr 19, 2010 at 5:22 PM, Simon Riggs wrote:
> > On Mon, 2010-04-19 at 17:08 -0400, Robert Haas wrote:
> >
> >> Oh. Then I'm confused. Tom said: "as of 9.0, it's necessary to
> >> connect to some database in order to proceed with aut
On Mon, Apr 19, 2010 at 5:22 PM, Simon Riggs wrote:
> On Mon, 2010-04-19 at 17:08 -0400, Robert Haas wrote:
>
>> Oh. Then I'm confused. Tom said: "as of 9.0, it's necessary to
>> connect to some database in order to proceed with auth checking". Why
>> is that necessary
>
> It's not, I just expl
On Mon, Apr 19, 2010 at 5:12 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Mon, Apr 19, 2010 at 5:04 PM, Alvaro Herrera
>> wrote:
>> > Robert Haas escribió:
>> >> On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane wrote:
>> >
>> >> > The only way I can think of to improve that without going bac
Simon Riggs escribió:
> On Mon, 2010-04-19 at 17:08 -0400, Robert Haas wrote:
>
> > Oh. Then I'm confused. Tom said: "as of 9.0, it's necessary to
> > connect to some database in order to proceed with auth checking". Why
> > is that necessary
>
> It's not, I just explained how to do it without
On Mon, 2010-04-19 at 17:08 -0400, Robert Haas wrote:
> Oh. Then I'm confused. Tom said: "as of 9.0, it's necessary to
> connect to some database in order to proceed with auth checking". Why
> is that necessary
It's not, I just explained how to do it without.
--
Simon Riggs www.2n
Robert Haas escribió:
> On Mon, Apr 19, 2010 at 5:04 PM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >> On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane wrote:
> >
> >> > The only way I can think of to improve that without going back to flat
> >> > files would be to develop a way for backends to
On Mon, Apr 19, 2010 at 5:04 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane wrote:
>
>> > The only way I can think of to improve that without going back to flat
>> > files would be to develop a way for backends to switch databases after
>> > initial
Robert Haas escribió:
> On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane wrote:
> > The only way I can think of to improve that without going back to flat
> > files would be to develop a way for backends to switch databases after
> > initial startup, so that auth could be done in a predetermined databas
On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Point of note on giving information to the bad guys: if a
>> should-be-rejected connection request attempts to connect to a
>> non-existent database, we say "database does not exist".
>
> Yeah. This was an acknowledged sho
On Mon, 2010-04-19 at 16:30 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > Point of note on giving information to the bad guys: if a
> > should-be-rejected connection request attempts to connect to a
> > non-existent database, we say "database does not exist".
>
> Yeah. This was an acknowledge
Simon Riggs writes:
> Point of note on giving information to the bad guys: if a
> should-be-rejected connection request attempts to connect to a
> non-existent database, we say "database does not exist".
Yeah. This was an acknowledged shortcoming of the changes to eliminate
flat-file storage of
On Thu, 2010-04-15 at 09:44 -0400, Tom Lane wrote:
> Maybe uaImplicitReject for the end-of-file case would be
> the most readable way.
uaImplicitReject capability added.
We're now free to bikeshed on exact wording. After much heavy thinking,
message is "pg_hba.conf rejects..." with no hint (yet?)
On Wed, Apr 14, 2010 at 08:37:18PM -0400, Robert Haas wrote:
> On Wed, Apr 14, 2010 at 8:31 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Robert Haas writes:
> >> > What's wrong with something like "connection not permitted" or
> >> > "connection not authorized"?
> >>
> >> The case that we're
Stephen Frost writes:
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>> So instead of the typical "reject" instruction we also add a
>> "rejectverbose" instruction that has a more verbose message.
> Erm, so we'd add an option for this? That strikes me as pretty
> excessive.
I think Simon's poin
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> So instead of the typical "reject" instruction we also add a
> "rejectverbose" instruction that has a more verbose message. Docs would
> describe it as an additional instruction to assist with debugging a
> complex pg_hba.conf, with warning tha
On Thu, 2010-04-15 at 00:24 -0400, Tom Lane wrote:
> Robert Haas writes:
> > So you'd prefer a message that is sometimes flat-out wrong over a
> > message that is correct but less informative in the common case? I
> > guess that could be right call, but it's not what I'd pick.
>
> Well, as I sai
Tom Lane wrote:
> Robert Haas writes:
>> So you'd prefer a message that is sometimes flat-out wrong over a
>> message that is correct but less informative in the common case? I
>> guess that could be right call, but it's not what I'd pick.
>
> Well, as I said, I think the only way to really impr
Robert Haas writes:
> So you'd prefer a message that is sometimes flat-out wrong over a
> message that is correct but less informative in the common case? I
> guess that could be right call, but it's not what I'd pick.
Well, as I said, I think the only way to really improve this message
is to us
On Wed, Apr 14, 2010 at 10:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> OK, how about "connection not authorized by pg_hba.conf"?
>
> This is still not especially helpful for novice DBAs. We want to point
> them in the direction that they need to add an entry to pg_hba.conf,
> which is 99% li
Robert Haas writes:
> OK, how about "connection not authorized by pg_hba.conf"?
This is still not especially helpful for novice DBAs. We want to point
them in the direction that they need to add an entry to pg_hba.conf,
which is 99% likely to be what's wanted. The current wording provides
that
On Wed, Apr 14, 2010 at 8:31 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>> > What's wrong with something like "connection not permitted" or
>> > "connection not authorized"?
>>
>> The case that we're trying to cater to with the existing wording is
>> novice DBAs, who are li
Tom Lane wrote:
> Robert Haas writes:
> > What's wrong with something like "connection not permitted" or
> > "connection not authorized"?
>
> The case that we're trying to cater to with the existing wording is
> novice DBAs, who are likely to stare at such a message and not even
> realize that pg
Robert Haas writes:
> What's wrong with something like "connection not permitted" or
> "connection not authorized"?
The case that we're trying to cater to with the existing wording is
novice DBAs, who are likely to stare at such a message and not even
realize that pg_hba.conf is what they need to
On Wed, Apr 14, 2010 at 8:19 PM, Tom Lane wrote:
> I'm thinking there isn't anything much we can do here without using a
> different message wording for a match to a REJECT entry. So it's a
> straight-up tradeoff of possible security information leakage against
> whether a different wording is re
I wrote:
> Robert Haas writes:
>> On Wed, Apr 14, 2010 at 4:24 PM, Aidan Van Dyk wrote:
>>> I think it sort of just died. I'm in favour of making sure we don't
>>> give out any extra information, so if the objection to the message is
>>> simply that "no pg_hba.conf entry" is "counterfactual" whe
Robert Haas writes:
> On Wed, Apr 14, 2010 at 4:24 PM, Aidan Van Dyk wrote:
>> I think it sort of just died. I'm in favour of making sure we don't
>> give out any extra information, so if the objection to the message is
>> simply that "no pg_hba.conf entry" is "counterfactual" when there is an
>
On Wed, Apr 14, 2010 at 4:51 PM, Robert Haas wrote:
> On Wed, Apr 14, 2010 at 4:28 PM, Robert Haas wrote:
>> On Wed, Apr 14, 2010 at 4:24 PM, Aidan Van Dyk wrote:
>>> I think it sort of just died. I'm in favour of making sure we don't
>>> give out any extra information, so if the objection to t
On Wed, Apr 14, 2010 at 4:28 PM, Robert Haas wrote:
> On Wed, Apr 14, 2010 at 4:24 PM, Aidan Van Dyk wrote:
>> I think it sort of just died. I'm in favour of making sure we don't
>> give out any extra information, so if the objection to the message is
>> simply that "no pg_hba.conf entry" is "co
On Wed, Apr 14, 2010 at 4:24 PM, Aidan Van Dyk wrote:
> I think it sort of just died. I'm in favour of making sure we don't
> give out any extra information, so if the objection to the message is
> simply that "no pg_hba.conf entry" is "counterfactual" when there is an
> entry rejecting it, how a
* Bruce Momjian [100414 16:20]:
> Joshua Tolley wrote:
> -- Start of PGP signed section.
> > On Wed, Apr 07, 2010 at 01:07:21PM -0400, Robert Haas wrote:
> > > On Wed, Apr 7, 2010 at 10:46 AM, Tom Lane wrote:
> > > > Simon Riggs writes:
> > > >> When there is a specific reject rule, why does the
Joshua Tolley wrote:
-- Start of PGP signed section.
> On Wed, Apr 07, 2010 at 01:07:21PM -0400, Robert Haas wrote:
> > On Wed, Apr 7, 2010 at 10:46 AM, Tom Lane wrote:
> > > Simon Riggs writes:
> > >> When there is a specific reject rule, why does the server say
> > >> FATAL: ?no pg_hba.conf ent
On Wed, Apr 07, 2010 at 01:07:21PM -0400, Robert Haas wrote:
> On Wed, Apr 7, 2010 at 10:46 AM, Tom Lane wrote:
> > Simon Riggs writes:
> >> When there is a specific reject rule, why does the server say
> >> FATAL: no pg_hba.conf entry
> >
> > It's intentional. We try to expose the minimum amou
On Wed, Apr 7, 2010 at 10:46 AM, Tom Lane wrote:
> Simon Riggs writes:
>> When there is a specific reject rule, why does the server say
>> FATAL: no pg_hba.conf entry
>
> It's intentional. We try to expose the minimum amount of knowledge
> about the contents of pg_hba.conf to potential attacker
> Clearly needs to be secure. Does the second message give any information
> to a would-be hacker than the first? I don't think so, but it certainly
> helps an admin work out if they've missed something.
I think this question needs a bona fide network security geek to decide,
rather than us datab
Jaime Casanova writes:
> On Wed, Apr 7, 2010 at 10:46 AM, Tom Lane wrote:
>> It's intentional. Â We try to expose the minimum amount of knowledge
>> about the contents of pg_hba.conf to potential attackers.
> i just tried it in CVS and in 8.4 and when i put a reject rule on
> pg_hba.conf what i
On Wed, Apr 7, 2010 at 10:46 AM, Tom Lane wrote:
> Simon Riggs writes:
>> When there is a specific reject rule, why does the server say
>> FATAL: no pg_hba.conf entry
>
> It's intentional. We try to expose the minimum amount of knowledge
> about the contents of pg_hba.conf to potential attacker
Simon Riggs writes:
> When there is a specific reject rule, why does the server say
> FATAL: no pg_hba.conf entry
It's intentional. We try to expose the minimum amount of knowledge
about the contents of pg_hba.conf to potential attackers.
regards, tom lane
--
Sent vi
When there is a specific reject rule, why does the server say
FATAL: no pg_hba.conf entry
That sounds like an administrative error, rather than a specific
decision on the part of an admin to reject the connection. Suggested
message would be
FATAL: connection rejected for host "xxx", user "xxx
57 matches
Mail list logo
