Re: [HACKERS] TODO list updated
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] TODO list updated |
Дата | |
Msg-id | 200001131557.KAA29869@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] TODO list updated (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] TODO list updated
|
Список | 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 по дате отправления: