Bruce Momjian writes:
> Does anyone have a comment on this? I wrote it a month ago.
The fact that the database server is wide-open in the default installation
is surely not good, but the problem is that we don't have a universally
accepted way to lock it down. We could make password authentication the
default, but that would annoy a whole lot of people. Another option would
be to set the unix domain socket permissions to 0200 by default, so only
the user that's running the server can get in. I could live with that;
not sure about others.
> > > Richard Huxton <[EMAIL PROTECTED]> 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
> > [EMAIL PROTECTED] | (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
> >
>
>
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
