Re: Indent authentication overloading - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Indent authentication overloading
Date
Msg-id 4411.1290104510@sss.pgh.pa.us
Whole thread Raw
In response to Re: Indent authentication overloading  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Indent authentication overloading
Re: Indent authentication overloading
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
>> We use it. Do you have an alternative that doesn't lower security
>> besides Kerberos? Anti-ident arguments are straw man arguments - "If
>> you setup identd badly or don't trust remote root or your network,
>> ident sucks as an authentication mechanism".

> Actually, you're trusting that nobody can add their own machine as a 
> node on your network.  All someone has to do is plug their linux laptop 
> into a network cable in your office and they have free access to the 
> database.

You're assuming the OP is using ident for wild-card IP ranges rather
than specific IP addresses.  I agree that ident is *hard* to set up
securely, but that doesn't mean it's entirely insecure.

> I don't think anyone is talking about eliminating it, just 
> distinguishing ident-over-TCP from unix-socket-same-user, which are 
> really two different authentication mechanisms.

> HOWEVER, I can't see any way of doing this which wouldn't cause a 
> significant amount of backwards-compatibility confusion.

I thought the proposal on the table was to add "peer" (or some other
name) to refer to the unix-socket auth method, and use that term
preferentially in the docs, while continuing to accept "ident" as an
old name for it.  Is that really too confusing?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: final patch - plpgsql: for-in-array
Next
From: Magnus Hagander
Date:
Subject: Re: Indent authentication overloading