Re: [HACKERS] TODO list updated - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] TODO list updated
Date
Msg-id 200001131557.KAA29869@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] TODO list updated  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] TODO list updated
List pgsql-hackers
> After thinking about it a little more, I wonder if I was too optimistic
> to say that an initdb script could transfer the password securely.
> Consider: we can get the password with
> 
>     echo "Please enter password for postgres superuser: "
>     read PASSWORD
> 
> and now the password is in a shell variable of the shell running initdb,
> and hasn't been exposed anywhere else.  So far so good, but now what?
> You can't securely do
> 
>     echo $PASSWORD | backend
> 
> or
>     echo $PASSWORD > allegedly-secure-temp-file

This is secure.  echo is a shell builtin, and does not invoke a separate
process with arguments.

> (Actually, you'd want it to do a few more pushups: turn off tty
> echoing before prompting for password, read password twice and
> check it was entered the same both times, retry if not, etc.
> Another reason that a pure shell script isn't really up to the
> job is that AFAIR it can't easily turn off tty echoing.)

That is the part that is hard to do in a shell, except I think there are
stty settings for this.

I just did:stty -echoread PASS stty echoecho $PASS

and it worked perfectly:
#$ /bjm/x          <- typed test heretest               

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] How PG parser search (build-in) function?
Next
From: Peter Eisentraut
Date:
Subject: initdb (Re: [HACKERS] TODO list updated)