Re: Bug in createlang?

To address this issue, I have added the following paragraph to the
installation instructions:

   However, while the directory contents are secure, the default
   <filename>pg_hba.conf</filename> authentication of
   <literal>trust</literal> allows any local user to become the
   superuser and connect to the database. If you don't trust your local
   users, we recommend you use the <command>initdb</command> option
   <option>-W</option> or <option>--pwprompt</option> to assign a
   password to the superuser and modify your
   <filename>pg_hba.conf</filename> accordingly. (Another option:
   Your operating system may support <literal>ident</literal> for
   local connections.)


---------------------------------------------------------------------------

> > Richard Huxton <dev@archonet.com> writes:
> > > "Thomas T. Veldhouse" wrote:
> > >> Why does it ask 4 times?
> >
> > > createlang is just a script - it basically runs "/path/to/psql $QUERY" -
> > > each query connects a separate time.
> >
> > Note that running a setup that requires password auth for the DBA will
> > also be a major pain in the rear when running pg_dumpall: one password
> > prompt per database, IIRC.  We have other scripts that make more than
> > one database connection, too.
>
> This brings up an issue I am concerned about.  Right now, when we
> install the database with initdb, we basically are wide-opened to any
> local user who wants to connect to the database as superuser.  In fact,
> someone could easily install a function in template1 that bypasses
> database security so even after you put a password on the superuser and
> others, they could bypass security.
>
> Do people have a good solution for this problem?  Should be be
> installing a password for the super-user at initdb time?  I see initdb
> has this option:
>
>        --pwprompt
>
>        -W     Makes  initdb prompt for a password of the database
>               superuser. If you  don't  plan  on  using  password
>               authentication,  this  is not important.  Otherwise
>               you won't be able to  use  password  authentication
>               until you have a password set up.
>
> Do people know they should be using this initdb option if they don't
> trust their local users?  I see no mention of it in the INSTALL file.
>
> I see it does:
>
> # set up password
> if [ "$PwPrompt" ]; then
>     $ECHO_N "Enter new superuser password: "$ECHO_C
>     stty -echo > /dev/null 2>&1
>     read FirstPw
>     stty echo > /dev/null 2>&1
>     echo
>     $ECHO_N "Enter it again: "$ECHO_C
>     stty -echo > /dev/null 2>&1
>     read SecondPw
>     stty echo > /dev/null 2>&1
>     echo
>     if [ "$FirstPw" != "$SecondPw" ]; then
>         echo "Passwords didn't match." 1>&2
>         exit_nicely
>     fi
>     echo "ALTER USER \"$POSTGRES_SUPERUSERNAME\" WITH PASSWORD '$FirstPw'" \
>         | "$PGPATH"/postgres $PGSQL_OPT template1 > /dev/null || exit_nicely
>     if [ ! -f $PGDATA/global/pg_pwd ]; then
>         echo "The password file wasn't generated. Please report this problem." 1>&2
>         exit_nicely
>     fi
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@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