Re: libpq: decouple the .pgpass lookup port from the connection port - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: libpq: decouple the .pgpass lookup port from the connection port
Date
Msg-id ak6FwxXWcBTvvpPo@msg.df7cb.de
Whole thread
Responses Re: libpq: decouple the .pgpass lookup port from the connection port
List pgsql-hackers
Re: Diego
> Why the port wildcard is not enough
> -----------------------------------
> 
> One can write the entry with a wildcard port:
> 
>     db.example.com:*:appdb:alice:secret
> and it does match the tunnel. But the wildcard over-matches: a single
> local forwarding port (say 54321, or even a fixed local port reused for
> several tunnels at different times) ends up matching every server reached
> through that port,

If you are giving the correct remote name to libpq, the rule won't
match several different hosts. If you don't care about that part, you
don't need anything extra and could just match on localhost:54321 (or
localhost:*).

> so the same password line can be applied to different
> servers. That is precisely the kind of "password sent to the wrong
> server" situation the 2018 host fix was trying to avoid. The wildcard
> trades safety for convenience; it is not a substitute for matching the
> real server port.

Don't use a wildcard, put :54321 in.

TBH I don't see why yet more connection parameters are required when
the problem is already solved by setting the hostname/hostaddr
correctly. (The part that remains when doing that can be avoided by
not reusing ports I think. You should do that anyway for general
sanity.)

>     - pgpassport / passfileport (it only affects the password file)

Is this proposal just a giant buildup for a "PG passport" joke? :)

Christoph



pgsql-hackers by date:

Previous
From: Diego
Date:
Subject: Re: [PATCH] - Re: libpq: decouple the .pgpass lookup port from the connection port
Next
From: Srinath Reddy Sadipiralla
Date:
Subject: Re: SQL/JSON: JSON_TRANSFORM (SQL standard, subclause 6.44)