Re: [HACKERS] TODO list updated

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] TODO list updated
Дата
Msg-id 12671.947778315@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] TODO list updated  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: [HACKERS] TODO list updated  (Bruce Momjian <pgman@candle.pha.pa.us>)
initdb (Re: [HACKERS] TODO list updated)  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Re: [HACKERS] TODO list updated  (Karl DeBisschop <kdebisschop@range.infoplease.com>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I will be responsible to make sure the password doesn't get into a
> command as an argument.  sed has a -f command that will take it's regex
> input from a file.  That is the solution, though the umask has to be set
> to make sure the temp file is not readable by anyone else.

Another possibility is not to try to 'sed' the password into the initial
database contents, but to run an ALTER USER command (using a standalone
backend) after we've done the initial setup of template1.  As long as
this is done before a postmaster is started, it's perfectly safe ---
no one other than the postgres user will have been able to connect to
the database yet.

Doing it this way, the password would need to appear in the stdin input
of that standalone backend, but not anyplace else.

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

orecho $PASSWORD > allegedly-secure-temp-file

or evenbackend <<EOF    ALTER USER ... PASSWORD $PASSWORDEOF

(the latter *looks* good, but way too many shells implement
here-documents by creating a temp file to put the data in;
do you want to trust the shell to make the here-doc secure?)

What I am starting to think is that we do need a C program.  However,
it could be very small; it shouldn't try to do all of what initdb does.
All it needs to do is fetch the password from stdin and then echo it
to stdout in an ALTER USER command.  The invocation in initdb would
look something like
securepassword $SUPERUSERNAME | standalone-backend ...

and the code would be on the order of
fprintf(stderr, "Please enter password for %s: ", argv[1]);fgets(stdin, password);printf("ALTER USER %s PASSWORD
'%s'\n",argv[1], password);
 

(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.)
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Don Baccus
Дата:
Сообщение: Re: [HACKERS] Re: Informix and OUTER join syntax
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] How PG parser search (build-in) function?