Re: [HACKERS] TODO list updated

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] TODO list updated
Date: 2000-01-13 01:26:54
Message-ID: 11294.947726814@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The Hermit Hacker <scrappy(at)hub(dot)org> writes:
> On Wed, 12 Jan 2000, Bruce Momjian wrote:
>> OK, now we have to decide if we are going to require this be done as
>> part of initdb. I am inclined to say the user _has_ to be _prompted_ in
>> a secure matter for the password as part of initdb. Have a command-line
>> switch for the password is not secure, IMHO, though it is better than
>> nothing.

> If we do a 'CREATE USER <user> WITH PASSWORD <pass>', its no more secure
> then using a command line switch for password ...

Yes it is --- if you have a shell script that is invoked by
initdb --password pgsqlPassword ...
then anyone else on the same machine who happens to be doing a "ps"
meanwhile will see your password.

Note that if initdb is a shell script, then it still has to be very
careful what it does with the password; put it in any command line
for a program invoked by the script, and the leak is back with you.
A C-program version of initdb would be a lot safer. But in theory you
can pass the password to the backend without exposing it in any command
line (put it in a data file instead, say).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-01-13 01:52:22 Re: [HACKERS] TODO list updated
Previous Message Hiroshi Inoue 2000-01-13 01:16:15 RE: [HACKERS] TODO list updated