Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
I don't know which platforms it is secure/insecure on, but I can
certainly imagine secure systems where ps(1) data in general is viewed
as sensitive and thus not made globally visible.
It's imaginable, but can you point to any real exam
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't offhand know of any Unix platforms where they cannot be found
>> out
> I don't know which platforms it is secure/insecure on, but I can
> certainly imagine secure systems where ps(1) data in general is viewed
> as sensitive and
Tom Lane wrote:
I don't offhand know of any Unix platforms where they cannot be found
out
I don't know which platforms it is secure/insecure on, but I can
certainly imagine secure systems where ps(1) data in general is viewed
as sensitive and thus not made globally visible.
My inclination
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think that using -P for pg_autovacuum is just plain stupid, even on a
>> nominally secure single-user box.
> Assuming that command-line parameters are actually globally visible on
> your platform, which isn't necessarily the case.
I
Tom Lane wrote:
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.
Neil Conway <[EMAIL PROTECTED]> 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, thin
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.
-Neil
Tom Lane wrote:
psql, pg_dump, etc allow password specification from stdin and from
.pgpass, never on the command line. There is a reason why they are all
designed like that. pg_autovacuum hasn't been studied carefully enough
I guess, because we should never have let a security hole like this g
Dave Page wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
I would argue actually that this switch is a horrible idea and we
must take it out entirely. The method Ian proposes for hiding the
password after reading it is certainly not portable in the slightest,
a
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 24 May 2005 16:02
> To: Dave Page
> Cc: Ian FREISLICH; pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] [PATCH] pg_autovacuum commandline
> password hiding.
>
> "Dave Page
Tom Lane wrote:
psql, pg_dump, etc allow password specification from stdin and from
.pgpass, never on the command line. There is a reason why they are all
designed like that. pg_autovacuum hasn't been studied carefully enough
I guess, because we should never have let a security hole like thi
"Dave Page" writes:
>> Which is exactly why we don't (and won't) provide such a switch.
> Err, yes we do:
Um, sorry, I totally misread Ian's patch as a proposal that we add a
password switch (I hate unidiffs ;-)).
I would argue actually that this switch is a horrible idea and we
must take it ou
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: 24 May 2005 15:17
> To: Ian FREISLICH
> Cc: pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] [PATCH] pg_autovacuum commandline
> password hiding.
&g
Ian FREISLICH <[EMAIL PROTECTED]> writes:
> ... The only thing is that
> pg_autovacuum keeps the password supplied on the commandline so
> anyone that does a 'ps' can get the database superuser password.
Which is exactly why we don't (and won't) provide such a switch.
Use ~/.pgpass instead.
Ian FREISLICH wrote:
Does pg_autovacuum use ~/.pgpass?
Yes (any libpq-based app will).
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Neil Conway wrote:
> Ian FREISLICH wrote:
> > I'm not sure if you've done this for a later version of pg_autovacuum.
> > I'm using what came with postgres-7.4.6. For database security on
> > a shared server (~800 logins) it's best to set the superuser password
> > and not allow passwordless connec
Ian FREISLICH wrote:
I'm not sure if you've done this for a later version of pg_autovacuum.
I'm using what came with postgres-7.4.6. For database security on
a shared server (~800 logins) it's best to set the superuser password
and not allow passwordless connections. The only thing is that
pg_a
Hi
I'm not sure if you've done this for a later version of pg_autovacuum.
I'm using what came with postgres-7.4.6. For database security on
a shared server (~800 logins) it's best to set the superuser password
and not allow passwordless connections. The only thing is that
pg_autovacuum keeps the
18 matches
Mail list logo
