Re: [GENERAL] Bug in createlang?
> 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. Whatever you suggest. We basically create a world-writeable socket/database when we do initdb. It is similar to a product installing in a world-writable directory. I realize you can lock it down later, but it seems people need to lock it down _before_ doing initdb or somehow keep it locked down until they set security. Our new SO_PEERCRED/SCM_CREDS gives us a lockdown option on Linux/BSD platforms, but not on the others. If we do the socket permissions thing for initdb, when do we start setting the socket permissions properly? I realize there is no easy answer. I just wanted people to know this is a security hole. -- 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 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Bug in createlang?
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
Re: [GENERAL] Bug in createlang?
> 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
