Thread: postgresql-7.1.3 pg_ctl password authentication and startup
The problem:
If password authentication is set, then startup
blocks waiting for a password to be given in stdin.
System:
FreeBSD 4.4
postgresql runs under user/group pgsql
data directory owned by pgsql
Workaround:
Modified the pg_ctl script to redirect a one line
password file to "$PGPATH/psql". The passwd file
exists in the data directory.
PASSFILE=$PGDATA/postmaster.passwd
If the passwd file does not exist, an empty one will
be created with perm 600.
Security:
If someone has root or pgsql os user access, then
they
can alter the data directory at will anyways. Putting
a plaintext passwd file in the data directory that
regular users cannot access anyways does not represent
any more of a security hazard that if someone had
access to the master.passwd files.
Workaround a bit more secure than allowing trust to
all local users.
--- pg_ctl.sh Sat Apr 21 04:23:58 2001
+++ /usr/local/bin/pg_ctl Sat Sep 22 12:39:03
2001
@@ -56,8 +56,8 @@
# Placed here during build
-bindir='@bindir@'
-VERSION='@VERSION@'
+bindir='/usr/local/bin'
+VERSION='7.1.3'
# protect the log file
umask 077
@@ -226,6 +226,11 @@
DEFPOSTOPTS=$PGDATA/postmaster.opts.default
POSTOPTSFILE=$PGDATA/postmaster.opts
PIDFILE=$PGDATA/postmaster.pid
+PASSFILE=$PGDATA/postmaster.passwd
+if [ ! -e $PASSFILE ];then
+ touch $PASSFILE
+ chmod 600 $PASSFILE
+fi
if [ $op = "status" ];then
if [ -f $PIDFILE ];then
@@ -347,6 +352,10 @@
do
# FIXME: This is horribly misconceived.
# 1) If password authentication is set up, the
connection will fail.
+# Kinda fixed. If password is set up, and the
$PASSFILE
+# does not exist, then it will fail. If password
is setup
+# and passwd file exists with the passwd, then
it will succeed.
+# If password auth is not set, this will still
work.
# 2) If a virtual host is set up, the connection may
fail.
# 3) If network traffic filters are set up tight
enough, the connection
# may fail.
@@ -357,7 +366,7 @@
# 6) If the dynamic loader is not set up correctly
(for this user/at
# this time), psql will fail (to find libpq).
# 7) If psql is misconfigured, this may fail.
- if "$PGPATH/psql" -l >/dev/null 2>&1
+ if "$PGPATH/psql" -l >/dev/null 2>&1 <
$PASSFILE
then
break;
else
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
Can I get comments on this? It allows storage of a super-user password in a file under /data that gets passed in psql. I don't like the fact the password is stored unencrypted but that is needed to pipe into psql. For 7.2 *BSD, Linux, it would be better to set up local/indent but for other platforms I can see a use to it. > The problem: > If password authentication is set, then startup > blocks waiting for a password to be given in stdin. > > System: > FreeBSD 4.4 > postgresql runs under user/group pgsql > data directory owned by pgsql > > Workaround: > Modified the pg_ctl script to redirect a one line > password file to "$PGPATH/psql". The passwd file > exists in the data directory. > PASSFILE=$PGDATA/postmaster.passwd > If the passwd file does not exist, an empty one will > be created with perm 600. > > Security: > If someone has root or pgsql os user access, then > they > can alter the data directory at will anyways. Putting > a plaintext passwd file in the data directory that > regular users cannot access anyways does not represent > any more of a security hazard that if someone had > access to the master.passwd files. > Workaround a bit more secure than allowing trust to > all local users. > > --- pg_ctl.sh Sat Apr 21 04:23:58 2001 > +++ /usr/local/bin/pg_ctl Sat Sep 22 12:39:03 > 2001 > @@ -56,8 +56,8 @@ > > > # Placed here during build > -bindir='@bindir@' > -VERSION='@VERSION@' > +bindir='/usr/local/bin' > +VERSION='7.1.3' > > # protect the log file > umask 077 > @@ -226,6 +226,11 @@ > DEFPOSTOPTS=$PGDATA/postmaster.opts.default > POSTOPTSFILE=$PGDATA/postmaster.opts > PIDFILE=$PGDATA/postmaster.pid > +PASSFILE=$PGDATA/postmaster.passwd > +if [ ! -e $PASSFILE ];then > + touch $PASSFILE > + chmod 600 $PASSFILE > +fi > > if [ $op = "status" ];then > if [ -f $PIDFILE ];then > @@ -347,6 +352,10 @@ > do > # FIXME: This is horribly misconceived. > # 1) If password authentication is set up, the > connection will fail. > +# Kinda fixed. If password is set up, and the > $PASSFILE > +# does not exist, then it will fail. If password > is setup > +# and passwd file exists with the passwd, then > it will succeed. > +# If password auth is not set, this will still > work. > # 2) If a virtual host is set up, the connection may > fail. > # 3) If network traffic filters are set up tight > enough, the connection > # may fail. > @@ -357,7 +366,7 @@ > # 6) If the dynamic loader is not set up correctly > (for this user/at > # this time), psql will fail (to find libpq). > # 7) If psql is misconfigured, this may fail. > - if "$PGPATH/psql" -l >/dev/null 2>&1 > + if "$PGPATH/psql" -l >/dev/null 2>&1 < > $PASSFILE > then > break; > else > > __________________________________________________ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Can I get comments on this?
Ugh.
> It allows storage of a super-user password
> in a file under /data that gets passed in psql. I don't like the fact
> the password is stored unencrypted
Entirely unacceptable IMHO. We just spent a large amount of work to
eliminate the need to keep any unencrypted passwords inside $PGDATA
... and this patch proposes to sling one right back in there, in an
easy-to-find place no less. Mess up the protection on $PGDATA, and
you've given away the store.
pg_ctl is certainly in need of work for systems that use password
security, but this is not a good fix.
regards, tom lane