Re: control pg_hba.conf via SQL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: control pg_hba.conf via SQL
Date
Msg-id 14768.1143731656@sss.pgh.pa.us
Whole thread Raw
In response to Re: control pg_hba.conf via SQL  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: control pg_hba.conf via SQL  ("A.M." <agentm@themactionfaction.com>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> If your pg_hba.conf looks like
>> host    all    all    0.0.0.0/32    md5
>> there's not much call to update it dynamically ...

> There'll be a call to update it once - to 0.0.0.0/0 ;-)

Doh ;-).  Should make more effort to check my throwaway examples ...

> But it's not clear to me why a CONNECT right shouldn't encompass all
> the things that hba does, i.e. connect method, source address and auth
> method.

Because that stuff doesn't fit into either the syntax of GRANT or the
system tables that store grant information.  It's talking about concepts
that don't even exist in the SQL world (while users and databases
certainly do).

Also, we know from experience that there's value in applying an ordered
set of tests in pg_hba.conf --- in particular, rules about "local" vs
"local net" vs "anywhere" connections are most easily expressed that
way.  We would need some substitute rule or concept in order to do the
same work in GRANT, and I don't see what that would be.

Recently in another thread someone was remarking about how ugly MySQL's
authentication methods are.  I think that's in part because they have
chosen to wedge the client hostname into their concept of user.  It doesn't
fit nicely.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: control pg_hba.conf via SQL
Next
From: "D'Arcy J.M. Cain"
Date:
Subject: Re: Slony-I for circular replication