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 21 read FirstPw stty echo /dev/null 21 echo $ECHO_N Enter it again: $ECHO_C stty -echo /dev/null 21 read SecondPw stty echo /dev/null 21 echo if [ $FirstPw != $SecondPw ]; then echo Passwords didn't match. 12 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. 12 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?
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?
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 21 read FirstPw stty echo /dev/null 21 echo $ECHO_N Enter it again: $ECHO_C stty -echo /dev/null 21 read SecondPw stty echo /dev/null 21 echo if [ $FirstPw != $SecondPw ]; then echo Passwords didn't match. 12 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. 12 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
