Re: [HACKERS] TODO list updated

Bruce Momjian <pgman@candle.pha.pa.us>

From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>, The Hermit Hacker <scrappy@hub.org>, PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: 2000-01-13T15:57:33Z
Lists: 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 -echo
	read PASS 
	stty echo
	echo $PASS

and it worked perfectly:

	#$ /bjm/x  
			<- typed test here
	test               

-- 
  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, Pennsylvania 19026