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

From Tom Lane
Subject Re: [HACKERS] TODO list updated
Date
Msg-id 12671.947778315@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] TODO list updated  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] TODO list updated
initdb (Re: [HACKERS] TODO list updated)
Re: [HACKERS] TODO list updated
List 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 by date:

Previous
From: Don Baccus
Date:
Subject: Re: [HACKERS] Re: Informix and OUTER join syntax
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] How PG parser search (build-in) function?