On Mon, Dec 10, 2007 at 10:47:19PM -0500, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > Stephen Frost wrote:
> >> I'm going to have to vote 'silly' on this one.
>
> > It's a matter of being consistent. If we think such a facility shouldn't
> > be provided on security grounds, then we shouldn't allow it via a
> > backdoor, ISTM.
>
> Well, the problem with this approach is that libpq has no real means
> of knowing whether a string it's been passed was exposed on the command
> line or not. dbName might be secure, and for that matter the conninfo
> string passed to PQconnectdb might be insecure. Should we put in
> arbitrary restrictions on the basis of hypotheses about where these
> different arguments came from?
>
> It's also worth noting that we haven't removed the PGPASSWORD
> environment variable, even though that's demonstrably insecure on some
> platforms.
>
> I'm actually inclined to vote with Stephen that this is a silly change.
> I just put up the patch to show the best way of doing it if we're gonna
> do it ...
+1 on the silly.
If we want to prevent it for psql, we should actually prevent it *in* psql,
not in libpq. There are an infinite number of scenarios where it's
perfectly safe to put the password there... If we want to do it share, we
should add a function like PQSanitizeConnectionString() that will remove
it, that can be called from those client apps that may be exposing it.
There are also platforms that don't show the full commandline to other
users - or even other processes - that aren't affected, of course.
//Magnus