Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] pg_autovacuum commandline password hiding.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>,Ian FREISLICH <if(at)hetzner(dot)co(dot)za>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCH] pg_autovacuum commandline password hiding.
Date: 2005-05-25 02:44:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Neil Conway <neilc(at)samurai(dot)com> writes:
> Neil Conway wrote:
>> I think the reason there is at least some value in having this switch 
>> for pg_autovacuum is that pg_autovacuum is almost exclusively used in a 
>> situation in which the password can't be specified on the command-line

> Sorry, thinko: I meant interactively via the terminal.

Right.  I don't think it'd be worth the trouble to implement the
equivalent of -W (get the password from stdin), since as you say
the use-case for that is pretty tiny for autovacuum.

The question at hand is whether we want to support an obvious security
hole.  The argument that "some people will not care" applies with at
least as much force to psql or pg_dump, which at least have the grace
to not hang around and advertise their command-line parameters forever.
I think that using -P for pg_autovacuum is just plain stupid, even on a
nominally secure single-user box.  If you believe your box is secure,
why are you using password auth for local connections in the first
place?  Might as well set it up as "trust".  You certainly shouldn't
imagine that the password is securing anything when an always-on daemon
is advertising it to the world in its command line.

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Neil ConwayDate: 2005-05-25 02:49:42
Subject: Re: [PATCH] pg_autovacuum commandline password hiding.
Previous:From: Qingqing ZhouDate: 2005-05-25 02:14:16
Subject: fix a bogus line in dynahash.c

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group