Thread: Shouldn't .pgpass work with anything which uses libpq?
(Using PostgreSQL-7.3.1) I noticed that the new ~/.pgpass password file works with psql but not with my pgtclsh scripts, and I'm wondering: shouldn't it work with anything built on top of libpq? Digging into it a bit, I think no conninfo-based connection method will use .pgpass, including libpq PQconnectDB() and libpgtcl "pg_connect -conninfo". I think it is happening because .pgpass is only read if the password argument to PQsetdbLogin() is NULL. But if no password is supplied in a conninfo string, then "DefaultPassword" is used - this is an empty string, not NULL. Am I right? Is this behavior wrong?
ljb <lbayuk@mindspring.com> writes:
> Digging into it a bit, I think no conninfo-based connection method will use
> .pgpass, including libpq PQconnectDB() and libpgtcl "pg_connect -conninfo".
Seems like a bug to me too.
regards, tom lane
OK, here is a patch I applied to 7.3.X and CVS head to fix the problem. The basic issue is that PQsetdbLogin does the pgpass test and then calls PQconnectDB. The fix is to do the pgpass test in PQconnectDB so both PQsetdbLogin and PQconnectDB can use it. However, your posting brings up an interesting issue. Our current code makes no distinction between "" as a password, and a NULL password. They are both equivalent to "I have supplied no password". If you create a public user with an empty password, "", there is no way to log in as that user, because "" is considered to be "no password". I don't want to play with this in 7.3.X, but is it something we should consider cleaning up for 7.4? --------------------------------------------------------------------------- ljb wrote: > (Using PostgreSQL-7.3.1) > > I noticed that the new ~/.pgpass password file works with psql but not with > my pgtclsh scripts, and I'm wondering: shouldn't it work with anything > built on top of libpq? > > Digging into it a bit, I think no conninfo-based connection method will use > .pgpass, including libpq PQconnectDB() and libpgtcl "pg_connect -conninfo". > I think it is happening because .pgpass is only read if the password > argument to PQsetdbLogin() is NULL. But if no password is supplied in a > conninfo string, then "DefaultPassword" is used - this is an empty string, > not NULL. Am I right? Is this behavior wrong? > > ---------------------------(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 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: src/interfaces/libpq/fe-connect.c =================================================================== RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v retrieving revision 1.220 diff -c -c -r1.220 fe-connect.c *** src/interfaces/libpq/fe-connect.c 8 Jan 2003 16:21:53 -0000 1.220 --- src/interfaces/libpq/fe-connect.c 8 Jan 2003 21:28:52 -0000 *************** *** 314,319 **** --- 314,322 ---- conn->pguser = tmp ? strdup(tmp) : NULL; tmp = conninfo_getval(connOptions, "password"); conn->pgpass = tmp ? strdup(tmp) : NULL; + if (conn->pgpass == NULL || conn->pgpass[0] == '\0') + conn->pgpass = PasswordFromFile(conn->pghost, conn->pgport, + conn->dbName, conn->pguser); tmp = conninfo_getval(connOptions, "connect_timeout"); conn->connect_timeout = tmp ? strdup(tmp) : NULL; #ifdef USE_SSL *************** *** 511,519 **** conn->pgpass = strdup(pwd); else if ((tmp = getenv("PGPASSWORD")) != NULL) conn->pgpass = strdup(tmp); - else if ((tmp = PasswordFromFile(conn->pghost, conn->pgport, - conn->dbName, conn->pguser))) - conn->pgpass = tmp; else conn->pgpass = strdup(DefaultPassword); --- 514,519 ----
pgman@candle.pha.pa.us wrote: >... > OK, here is a patch I applied to 7.3.X and CVS head to fix the problem. > > The basic issue is that PQsetdbLogin does the pgpass test and then calls > PQconnectDB. The fix is to do the pgpass test in PQconnectDB so both > PQsetdbLogin and PQconnectDB can use it. (Sorry about that. I posted a patch to one of the lists but it may not have made it through. It looks like your patch is the same.) > However, your posting brings up an interesting issue. Our current code > makes no distinction between "" as a password, and a NULL password. > They are both equivalent to "I have supplied no password". If you > create a public user with an empty password, "", there is no way to log > in as that user, because "" is considered to be "no password". > > I don't want to play with this in 7.3.X, but is it something we should > consider cleaning up for 7.4? There is a precedence for the current behavior. Another DBMS I've used takes an empty password for an account to mean "this account is disabled". Therefore it is impossible in that DBMS to have a valid account with no password. Which to me is equivalent to PostgreSQL saying "if passwords are enabled, it is impossible to login to an account with an empty or NULL password". I like that behavior.
ljb wrote: > > However, your posting brings up an interesting issue. Our current code > > makes no distinction between "" as a password, and a NULL password. > > They are both equivalent to "I have supplied no password". If you > > create a public user with an empty password, "", there is no way to log > > in as that user, because "" is considered to be "no password". > > > > I don't want to play with this in 7.3.X, but is it something we should > > consider cleaning up for 7.4? > > There is a precedence for the current behavior. Another DBMS I've used > takes an empty password for an account to mean "this account is disabled". > Therefore it is impossible in that DBMS to have a valid account with no > password. Which to me is equivalent to PostgreSQL saying "if passwords are > enabled, it is impossible to login to an account with an empty or NULL > password". I like that behavior. Oh, OK. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073