Reading psql password from stdin
We have recently realized that psql and pg_dump read passwords from
stdin, rather than from the more traditional /dev/tty. I would like to
change the default to /dev/tty and read from stdin only when /dev/tty
can't be opened.
Is this good or bad? I need votes.
--
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
Good, good, very good! being one of the people who steadfastly avoids PGUSER
and PGPASSWORD for security reasons, it would be nice t be able to do
$ psql db user < file
As the docs say you can. Would this change also allow the use of:
$ pg_dump > dumpfile
Which doesn't work when prompting for password, but that can be a stdout
issue.
I would enumerate these issues as the top annoyances with the postgres
client apps. Although I would place them very low compared to being able to
alter/remove columns.
Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"
Show quoted text
From: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Sun, 14 Oct 2001 19:07:25 -0400 (EDT)
To: PostgreSQL-general <pgsql-general@postgresql.org>
Subject: [GENERAL] Reading psql password from stdinWe have recently realized that psql and pg_dump read passwords from
stdin, rather than from the more traditional /dev/tty. I would like to
change the default to /dev/tty and read from stdin only when /dev/tty
can't be opened.Is this good or bad? I need votes.
-- 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 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
pg_dump does wait for passwords - version 7.1.x.
But the password prompts end up in the dumpfile.
That is to say, the Username: and/or Password: prompts end up in the
dumpfile and are not displayed on the screen.
Cheerio,
Link.
At 06:19 PM 14-10-2001 -0600, Keary Suska wrote:
Show quoted text
Good, good, very good! being one of the people who steadfastly avoids PGUSER
and PGPASSWORD for security reasons, it would be nice t be able to do
$ psql db user < file
As the docs say you can. Would this change also allow the use of:
$ pg_dump > dumpfile
Which doesn't work when prompting for password, but that can be a stdout
issue.I would enumerate these issues as the top annoyances with the postgres
client apps. Although I would place them very low compared to being able to
alter/remove columns.Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"
Correction:
The password promps only end up in the dumpfile for version 6.5.
pg_dump does wait and prompt for passwords if you use -u for version 7.1.x.
Cheerio,
Link.
At 06:19 PM 14-10-2001 -0600, Keary Suska wrote:
Show quoted text
Good, good, very good! being one of the people who steadfastly avoids PGUSER
and PGPASSWORD for security reasons, it would be nice t be able to do
$ psql db user < file
As the docs say you can. Would this change also allow the use of:
$ pg_dump > dumpfile
Which doesn't work when prompting for password, but that can be a stdout
issue.I would enumerate these issues as the top annoyances with the postgres
client apps. Although I would place them very low compared to being able to
alter/remove columns.Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"
Import Notes
Resolved by subject fallback
The proposed patch would fix this. Password prompts would go to the
terminal. Right now they got to stderr. Does your stderr go to the
dump file?
pg_dump does wait for passwords - version 7.1.x.
But the password prompts end up in the dumpfile.
That is to say, the Username: and/or Password: prompts end up in the
dumpfile and are not displayed on the screen.Cheerio,
Link.At 06:19 PM 14-10-2001 -0600, Keary Suska wrote:
Good, good, very good! being one of the people who steadfastly avoids PGUSER
and PGPASSWORD for security reasons, it would be nice t be able to do
$ psql db user < file
As the docs say you can. Would this change also allow the use of:
$ pg_dump > dumpfile
Which doesn't work when prompting for password, but that can be a stdout
issue.I would enumerate these issues as the top annoyances with the postgres
client apps. Although I would place them very low compared to being able to
alter/remove columns.Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
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 19026Oops, sorry, I see my question was answered.
---------------------------------------------------------------------------
Correction:
The password promps only end up in the dumpfile for version 6.5.pg_dump does wait and prompt for passwords if you use -u for version 7.1.x.
Cheerio,
Link.At 06:19 PM 14-10-2001 -0600, Keary Suska wrote:
Good, good, very good! being one of the people who steadfastly avoids PGUSER
and PGPASSWORD for security reasons, it would be nice t be able to do
$ psql db user < file
As the docs say you can. Would this change also allow the use of:
$ pg_dump > dumpfile
Which doesn't work when prompting for password, but that can be a stdout
issue.I would enumerate these issues as the top annoyances with the postgres
client apps. Although I would place them very low compared to being able to
alter/remove columns.Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
--
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