psql: default base and password reading
Hello,
in attachment I enclose patch on psql which fix two things:
1. If no database was given, template1 is assumed.
2. Password is reading from terminal (/dev/tty) rather than from stdin. It
was usable when we want to pipe sql script on psql and have set password at
the same time. It may be turned off, by pass -i option to psql. Then, psql
behave normally, like it is currently.
Sorry about increasing traffic, if it was already discussed, or it is solved
in other way.
--
## Adam Osuchowski adwol@polsl.gliwice.pl, adwol@silesia.linux.org.pl
## Silesian University of Technology, Computer Centre Gliwice, Poland
Attachments:
psql.patchtext/plain; charset=us-asciiDownload+20-7
Adam Osuchowski wrote:
Hello,
in attachment I enclose patch on psql which fix two things:
1. If no database was given, template1 is assumed.
Does this change the current behavior of assuming a database name which
is the same as the user's account name? I'm not sure why the new
behavior is better.
2. Password is reading from terminal (/dev/tty) rather than from stdin. It
was usable when we want to pipe sql script on psql and have set password at
the same time. It may be turned off, by pass -i option to psql. Then, psql
behave normally, like it is currently.
Interesting. Is this technique portable to other platforms (just asking;
I'm not sure myself)?
- Thomas
Adam Osuchowski <adwol@polsl.gliwice.pl> writes:
in attachment I enclose patch on psql which fix two things:
1. If no database was given, template1 is assumed.
That is a very large step backwards from the current behavior (default
to dbname = username). The last thing we want is to encourage people
to use template1 for routine operations.
2. Password is reading from terminal (/dev/tty) rather than from
stdin.
Hmm, that might be a good idea. Comments anyone?
regards, tom lane
Actually, I see problems with both of these:
IIRC, template1 is used as the base whenever you create a new database.
Having psql connect to it by default greatly increases the likelyhood
of unintended modification of template1, which then gets propogated to
every other database subsequently created.
Personally, I'd be happier if psql attempted to create a database in
the name of the logged in user rather than ever give access to template1
to someone who didn't ask for it. However, I think requiring the database
name is a good idea in general.
The password reading patch may be useful, but I suggest that you
reverse the meaning of the option, so that you do not change the
current behavior. This would be a normal practice for backward
compatibility.
-Brad
* Adam Osuchowski (adwol@polsl.gliwice.pl) [011012 01:59]:
Show quoted text
Hello,
in attachment I enclose patch on psql which fix two things:
1. If no database was given, template1 is assumed.
2. Password is reading from terminal (/dev/tty) rather than from stdin. It
was usable when we want to pipe sql script on psql and have set password at
the same time. It may be turned off, by pass -i option to psql. Then, psql
behave normally, like it is currently.Sorry about increasing traffic, if it was already discussed, or it is solved
in other way.--
## Adam Osuchowski adwol@polsl.gliwice.pl, adwol@silesia.linux.org.pl
## Silesian University of Technology, Computer Centre Gliwice, Poland
diff -ruN psql/common.c psql_patched/common.c --- psql/common.c Sun Apr 15 02:43:37 2001 +++ psql_patched/common.c Sun Oct 7 14:58:22 2001 @@ -176,6 +176,7 @@ { int length; char *destination; + static FILE *term = NULL;#ifdef HAVE_TERMIOS_H
struct termios t_orig,
@@ -190,24 +191,28 @@
fputs(prompt, stderr);prompt_state = true; + if (!term && pset.stdinPassword == false) + term = fopen("/dev/tty", "r"); + if (term == NULL || pset.stdinPassword == true) + term = stdin;#ifdef HAVE_TERMIOS_H if (!echo) { - tcgetattr(0, &t); + tcgetattr(fileno(term), &t); t_orig = t; t.c_lflag &= ~ECHO; - tcsetattr(0, TCSADRAIN, &t); + tcsetattr(fileno(term), TCSADRAIN, &t); } #endif- if (fgets(destination, maxlen, stdin) == NULL) + if (fgets(destination, maxlen, term) == NULL) destination[0] = '\0';#ifdef HAVE_TERMIOS_H if (!echo) { - tcsetattr(0, TCSADRAIN, &t_orig); + tcsetattr(fileno(term), TCSADRAIN, &t_orig); fputs("\n", stderr); } #endif @@ -223,7 +228,7 @@do { - if (fgets(buf, sizeof(buf), stdin) == NULL) + if (fgets(buf, sizeof(buf), term) == NULL) break; buflen = strlen(buf); } while (buflen > 0 && buf[buflen - 1] != '\n'); diff -ruN psql/help.c psql_patched/help.c --- psql/help.c Thu Mar 22 05:00:20 2001 +++ psql_patched/help.c Sun Oct 7 14:57:32 2001 @@ -103,6 +103,7 @@ puts(")");puts(" -H HTML table output mode (-P format=html)"); + puts(" -i Read password from stdin rather than terminal"); puts(" -l List available databases, then exit"); puts(" -n Disable readline"); puts(" -o <filename> Send query output to filename (or |pipe)"); diff -ruN psql/settings.h psql_patched/settings.h --- psql/settings.h Wed Apr 12 19:16:23 2000 +++ psql_patched/settings.h Sun Oct 7 14:49:16 2001 @@ -46,6 +46,7 @@char *progname; /* in case you renamed psql */
char *inputfile; /* for error reporting */
+ bool stdinPassword;
unsigned lineno; /* also for error reporting */bool issuper; /* is the current user a superuser? (used diff -ruN psql/startup.c psql_patched/startup.c --- psql/startup.c Fri Mar 23 01:36:38 2001 +++ psql_patched/startup.c Sun Oct 7 14:55:43 2001 @@ -331,6 +331,7 @@ {"field-separator", required_argument, NULL, 'F'}, {"host", required_argument, NULL, 'h'}, {"html", no_argument, NULL, 'H'}, + {"stdin", no_argument, NULL, 'i'}, {"list", no_argument, NULL, 'l'}, {"no-readline", no_argument, NULL, 'n'}, {"output", required_argument, NULL, 'o'}, @@ -364,14 +365,14 @@ memset(options, 0, sizeof *options);#ifdef HAVE_GETOPT_LONG - while ((c = getopt_long(argc, argv, "aAc:d:eEf:F:h:Hlno:p:P:qR:sStT:uU:v:VWxX?", long_options, &optindex)) != -1) + while ((c = getopt_long(argc, argv, "aAc:d:eEf:F:h:Hilno:p:P:qR:sStT:uU:v:VWxX?", long_options, &optindex)) != -1) #else /* not HAVE_GETOPT_LONG *//* * Be sure to leave the '-' in here, so we can catch accidental long * options. */ - while ((c = getopt(argc, argv, "aAc:d:eEf:F:h:Hlno:p:P:qR:sStT:uU:v:VWxX?-")) != -1) + while ((c = getopt(argc, argv, "aAc:d:eEf:F:h:Hilno:p:P:qR:sStT:uU:v:VWxX?-")) != -1) #endif /* not HAVE_GETOPT_LONG */ { switch (c) @@ -414,6 +415,9 @@ case 'H': pset.popt.topt.format = PRINT_HTML; break; + case 'i': + pset.stdinPassword = true; + break; case 'l': options->action = ACT_LIST_DB; break; @@ -571,6 +575,8 @@ if (used_old_u_option && !QUIET()) fprintf(stderr, "%s: Warning: The -u option is deprecated. Use -U.\n", pset.progname);+ if (!options->dbname) + options->dbname = "template1"; }
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
The password reading patch may be useful, but I suggest that you
reverse the meaning of the option, so that you do not change the
current behavior. This would be a normal practice for backward
compatibility.
I like the /dev/tty fix. I assumed we always read passwords from
/dev/tty and not stdin. I know of no other software that even allows
passwords from stdin. You usually have to use 'expect' for that very
purpose. I would not even supply an option to read it from stdin.
--
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 19026The password reading patch may be useful, but I suggest that you
reverse the meaning of the option, so that you do not change the
current behavior. This would be a normal practice for backward
compatibility.I like the /dev/tty fix. I assumed we always read passwords from
/dev/tty and not stdin. I know of no other software that even allows
passwords from stdin. You usually have to use 'expect' for that very
purpose. I would not even supply an option to read it from stdin.
Attached is an updated version of the patch. It does not have the
'template1' default because many people prefer our current behavior.
The patch uses /dev/tty if it can open it, and stdin if it can't. It
does not have a psql flag to force stdin because there is little reason
to read a password from stdin in any reasonable usage.
In fact, I wonder if we should just fail if we need to prompt for a
password and can't open /dev/tty. The function is simple_prompt() and
if we can't open /dev/tty, maybe we should just assume the user typed
nothing.
Comments?
--
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 19026Attachments:
/bjm/3text/plainDownload+10-5
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The patch uses /dev/tty if it can open it, and stdin if it can't. It
does not have a psql flag to force stdin because there is little reason
to read a password from stdin in any reasonable usage.
If we are reading the password from /dev/tty not stdin, then IMHO the
prompt for the password should be sent to /dev/tty not stderr.
In fact, I wonder if we should just fail if we need to prompt for a
password and can't open /dev/tty. The function is simple_prompt() and
if we can't open /dev/tty, maybe we should just assume the user typed
nothing.
Would be okay with me ...
regards, tom lane
In fact, I wonder if we should just fail if we need to prompt for a
password and can't open /dev/tty. The function is simple_prompt() and
if we can't open /dev/tty, maybe we should just assume the user typed
nothing.
Would be okay with me ...
On second thought --- are we creating any portability problems if we
assume /dev/tty exists? In particular, what about the Windows port
of psql? Will it still work?
regards, tom lane
In fact, I wonder if we should just fail if we need to prompt for a
password and can't open /dev/tty. The function is simple_prompt() and
if we can't open /dev/tty, maybe we should just assume the user typed
nothing.Would be okay with me ...
On second thought --- are we creating any portability problems if we
assume /dev/tty exists? In particular, what about the Windows port
of psql? Will it still work?
I am sure cygwin takes care of this. Certainly is would have to handle
it to allow Unix compatibility. If someone reports a problem, we can
#ifdef around it.
--
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 19026Bruce Momjian <pgman@candle.pha.pa.us> writes:
On second thought --- are we creating any portability problems if we
assume /dev/tty exists? In particular, what about the Windows port
of psql? Will it still work?
I am sure cygwin takes care of this.
Please recall that we have a *native* port of psql ... cygwin doesn't
help.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
On second thought --- are we creating any portability problems if we
assume /dev/tty exists? In particular, what about the Windows port
of psql? Will it still work?I am sure cygwin takes care of this.
Please recall that we have a *native* port of psql ... cygwin doesn't
help.
Ewe!
The only other mention of /dev/tty I see is in psql/command.c:
/* \s save history in a file or show it on the screen */
else if (strcmp(cmd, "s") == 0)
{
char *fname = scan_option(&string, OT_NORMAL, NULL, true);
success = saveHistory(fname ? fname : "/dev/tty");
if (success && !quiet && fname)
printf(gettext("Wrote history to %s.\n"), fname);
free(fname);
}
I can easily #ifdef around the /dev/tty open. Can someone comment on
what opening /dev/tty does on a Win32 machines without cygwin?
--
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 19026Bruce Momjian <pgman@candle.pha.pa.us> writes:
On second thought --- are we creating any portability problems if we
assume /dev/tty exists? In particular, what about the Windows port
of psql? Will it still work?I am sure cygwin takes care of this.
Please recall that we have a *native* port of psql ... cygwin doesn't
help.
OK, I read up on how BSD/OS does this and found getpass():
The getpass() function displays a prompt to, and reads in a password
from, /dev/tty. If this file is not accessible, getpass displays the
prompt on the standard error output and reads from the standard
input.
So even it tries for /dev/tty and falls back to stdin/stderr. The
attached patch does this.
--
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 19026Attachments:
/pgpatches/passwdtext/plainDownload+70-37
Tom Lane writes:
2. Password is reading from terminal (/dev/tty) rather than from
stdin.Hmm, that might be a good idea. Comments anyone?
I guarantee you that within 24 hours after such a patch were checked in
someone's going to complain that he has no /dev/tty.
Meanwhile, there are a couple of possible workarounds:
* PGPASSWORD environment variable.
* FIFOs
* (echo "Password"; pipe_input) | psql
A generalized option to read the password from any file might make sense,
though.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Tom Lane writes:
2. Password is reading from terminal (/dev/tty) rather than from
stdin.Hmm, that might be a good idea. Comments anyone?
I guarantee you that within 24 hours after such a patch were checked in
someone's going to complain that he has no /dev/tty.Meanwhile, there are a couple of possible workarounds:
* PGPASSWORD environment variable.
* FIFOs
* (echo "Password"; pipe_input) | psql
A generalized option to read the password from any file might make sense,
though.
Have you seen my later version that reads from stdin/stderr if /dev/tty
doesn't open. How is that?
--
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 19026Bruce Momjian writes:
Have you seen my later version that reads from stdin/stderr if /dev/tty
doesn't open. How is that?
Might as well use getpass() if available. My man page says "A getpass
function appeared in Version 7 AT&T UNIX.", so it should be available on
most systems.
However, I'm afraid many users have set up their systems to read the
password from stdin, so that should probably stay the default unless we
take a user poll.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes:
Might as well use getpass() if available. My man page says "A getpass
function appeared in Version 7 AT&T UNIX.", so it should be available on
most systems.
Hmm. HPUX's man page for getpass says:
STANDARDS CONFORMANCE
getpass(): AES, SVID2, SVID3, XPG2, XPG3, XPG4
However, it also says:
getpass() reads up to a newline or EOF from the file /dev/tty, after
prompting on the standard error output with the null-terminated string
prompt and disabling echoing. A pointer is returned to a null-
terminated string of at most 8 characters. If /dev/tty cannot be
opened, a NULL pointer is returned.
The 8-char limit is alone sufficient to disqualify it for use in psql.
regards, tom lane
Bruce Momjian writes:
Have you seen my later version that reads from stdin/stderr if /dev/tty
doesn't open. How is that?Might as well use getpass() if available. My man page says "A getpass
function appeared in Version 7 AT&T UNIX.", so it should be available on
most systems.However, I'm afraid many users have set up their systems to read the
password from stdin, so that should probably stay the default unless we
take a user poll.
OK, I am asking for votes for /dev/tty or stdin as the default for
reading passwords? I already have a few for /dev/tty and I assume one
for stdin (Peter E).
--
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 19026pgsql-patches is hardly the place to take a user poll ...
regards, tom lane
OK, send to general.
pgsql-patches is hardly the place to take a user poll ...
regards, tom lane
--
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 19026Bruce Momjian writes:
Have you seen my later version that reads from stdin/stderr if /dev/tty
doesn't open. How is that?Might as well use getpass() if available. My man page says "A getpass
function appeared in Version 7 AT&T UNIX.", so it should be available on
most systems.However, I'm afraid many users have set up their systems to read the
password from stdin, so that should probably stay the default unless we
take a user poll.
Vote request sent to 'general'.
Yes, a change will inconvenience some people and perhaps they will have
to resort to 'expect'. However, I can't think of one piece of
significant software that reads from stdin by default rather than
/dev/tty. It certainly makes this counter-intuitive:
cat script | psql test
If 'test' requires a password, our current code requires the password to
be the first line in the script. Though this can be convenient in some
cases, in most cases it is quite unexpected.
--
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