On Mon, Feb 13, 2006 at 10:00:34AM -0500, Andrew Dunstan wrote:
> Mark Woodward wrote:
> >I'm not so sure you need to be paranoid about it. The scenario is, at
> >startup or HUP, names are looked up and stored as IP addresses. Then hba
> >works as it is supposed too.
> If you do it like that you destroy the only real use case I can see for
> this that has much value, namely to handle cases where the address can
> change dynamically.
*nod*
Addresses change, and for a stable PostgreSQL server, this would hopefully
mean that PostgreSQL has uptime across these changes. :-)
> We have address ranges now; are you proposing to have those IN ADDITION
> to hostname parameters (as opposed to being an alternative)?
I like in addition. For example, at work, saying "a.blah.com" and "47.*"
would give me an inch more of comfort, as the organization is large, and
there are numerous channels to having the name changed - but at least if
I know that the name is within 47.*, I know that it isn't somebody in
another partner company connecting directly from their network.
Not bullet proof, but slightly more difficult to manipulate.
> We can over-egg this pudding massively. I suggest we start with a simple
> implementation and see what needs it leaves unfilled. I would vote for
> allowing a hostname (or list of hostnames?) to replace the address/mask
> params, and that at connect time we do a forward lookup trying for a
> match with the connecting address. If we get a match then that's the hba
> line that applies.
Yes.
> Frankly, any auth mechanism based on the name or address of the client
> is insecure. If you have people connecting across possibly insecure
> networks you should use SSL with client certificates signed by your own
> CA, or a similar approach.
Yes.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
