Re: control pg_hba.conf via SQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tino Wildenhain <tino(at)wildenhain(dot)de>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, BERTHOULE Emmanuel <pgdev(at)manberth(dot)homeip(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: control pg_hba.conf via SQL
Date: 2006-03-30 15:14:16
Message-ID: 14768.1143731656@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message D'Arcy J.M. Cain 2006-03-30 15:15:21 Re: Slony-I for circular replication
Previous Message Andrew Dunstan 2006-03-30 15:01:44 Re: control pg_hba.conf via SQL