Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
Andy Grimm escribió: > Sorry that it's been a couple of weeks, but I have gotten around to > working on a patch that address more of these concerns. The attached > patch should > > 1) allow arbitrary length passwords to be read from a file via initdb --pwfile > 2) allow the client to accept a password of arbitrary length at the > password prompt > 3) allow a password of arbitrary length in a pgpass file This patch is in an awkward position. It was submitted back in February and then ignored for months. It got added by Robert into this commitfest, but the submitter hasn't gotten involved at all. Then Heikki posted a review a month ao and pointed out a number of issues which are still waiting to be fixed. If this patch is something we want, then perhaps somebody else should grab it, fix the issues, and resubmit to the next commitfest. If we don't want it (and some have suggested) then we just quietly let the thread die here. I am marking it Returned with Feedback for now. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
On 15.02.2012 07:09, Andy Grimm wrote: Sorry that it's been a couple of weeks, but I have gotten around to working on a patch that address more of these concerns. The attached patch should 1) allow arbitrary length passwords to be read from a file via initdb --pwfile 2) allow the client to accept a password of arbitrary length at the password prompt 3) allow a password of arbitrary length in a pgpass file In #2 I say "allow the client to accept", because there's a pq_getmessage call in src/backend/libpq/auth.c which limits the password message length to 1000 characters. Changing that part of the code should allow longer passwords, but there may be other lurking backend issues after that, and I'm not concerned about going beyond 1000 at this point. Thanks for the patch. A few comments: * Most of the simple_prompt() calls are for passwords, which now have no limit, but there's a few others. How about we remove the maxlen argument altogether, and just have it always return a malloc'd string that can be arbitrarily long. (maybe with a sanity-check limit within simple_prompt(), like 100k) * .pg_service.conf handling still has a fixed limit on line length of 256 bytes. See parseServiceInfo() in fe-connect. I think we should lift that limit too, for the sake of consistency. You can pass a password in the service file, too. * Missed a few simple_prompt() calls in contrib (oid2name, vacuumlo, pgbench) - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
On Mon, Aug 27, 2012 at 12:33 PM, Alvaro Herrera wrote: > Excerpts from Bruce Momjian's message of lun ago 27 12:12:25 -0400 2012: >> >> Did we want this patch applied? Not enough demand? > > I think it should be in the next commitfest for discussion. I don't see > any reason to reject it. I think it needs some fixes, though, so a > formal review process is called for. +1. I added it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
On Sat, Jan 28, 2012 at 01:47:04PM -0500, Tom Lane wrote: > Euler Taveira de Oliveira writes: > > I don't see it as a bug but a limitation. Why do you need such a long > > password? > > Yeah, I think the reason we're not too consistent about this is that > nobody ever imagined that limits of 100 bytes or more would pose an > issue in practice. What's the use-case for passwords longer than > that? Thanks for all the feedback. I know it is a pain for me to re-ask these questions, but it allows us to know that these issues have gotten sufficient thought. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
Bruce Momjian writes: > Did we want this patch applied? Not enough demand? It seems a bit overengineered at this point. I realize Andy wasn't the one pushing to support arbitrary-length passwords originally, but I can't see adding this much code for that. I don't even see the value of allowing them to be more than 100 characters ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
Excerpts from Bruce Momjian's message of lun ago 27 12:12:25 -0400 2012: > > Did we want this patch applied? Not enough demand? I think it should be in the next commitfest for discussion. I don't see any reason to reject it. I think it needs some fixes, though, so a formal review process is called for. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
Did we want this patch applied? Not enough demand? --- On Wed, Feb 15, 2012 at 12:09:12AM -0500, Andy Grimm wrote: > On Sat, Jan 28, 2012 at 7:47 PM, Euler Taveira de Oliveira > wrote: > > On 28-01-2012 18:55, Andy Grimm wrote: > >> It's not uniform between the client and the server, though. > >> > > The server doesn't impose a hard limit for password length and AFAICS it > > should not because we aim for backward compatibility. > > > >> It sounds like you are suggesting > >> that rather than increase the limit in the simple_prompt calls, you'd > >> prefer to decrease the limit read from pwfile? That doesn't > >> particularly help me. > >> > > No, I am not. So there are three concerns here: (i) increase the limit for > > simple_prompt() and (ii) raise an error when we reach that limit and (iii) > > fix > > the PasswordFromFile(). Looking at your patch, it seems to fix only (i). > > Sorry that it's been a couple of weeks, but I have gotten around to > working on a patch that address more of these concerns. The attached > patch should > > 1) allow arbitrary length passwords to be read from a file via initdb --pwfile > 2) allow the client to accept a password of arbitrary length at the > password prompt > 3) allow a password of arbitrary length in a pgpass file > > In #2 I say "allow the client to accept", because there's a > pq_getmessage call in src/backend/libpq/auth.c which limits the > password message length to 1000 characters. Changing that part of the > code should allow longer passwords, but there may be other lurking > backend issues after that, and I'm not concerned about going beyond > 1000 at this point. > > --Andy > > >> require understanding of what the real password length limit in a > >> database is. > >> > > There is no such limit; it is stored in a text datatype. > > > > > > -- > > Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ > > PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento > diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c > index 99cf5b4..047b25e 100644 > --- a/src/bin/initdb/initdb.c > +++ b/src/bin/initdb/initdb.c > @@ -1303,8 +1303,8 @@ get_set_pwd(void) > /* >* Read password from terminal >*/ > - pwd1 = simple_prompt("Enter new superuser password: ", 100, > false); > - pwd2 = simple_prompt("Enter it again: ", 100, false); > + pwd1 = simple_prompt("Enter new superuser password: ", > MAX_PASSWD, false); > + pwd2 = simple_prompt("Enter it again: ", MAX_PASSWD, false); > if (strcmp(pwd1, pwd2) != 0) > { > fprintf(stderr, _("Passwords didn't match.\n")); > @@ -1323,7 +1323,7 @@ get_set_pwd(void) >* for now. >*/ > FILE *pwf = fopen(pwfilename, "r"); > - charpwdbuf[MAXPGPATH]; > + char*pwdbuf = calloc(1,1), buf[1024]; > int i; > > if (!pwf) > @@ -1332,7 +1332,27 @@ get_set_pwd(void) > progname, pwfilename, strerror(errno)); > exit_nicely(); > } > - if (!fgets(pwdbuf, sizeof(pwdbuf), pwf)) > + > + do > + { > + if (fgets(buf, sizeof(buf), pwf) == NULL) > + break; > + pwdbuf = realloc( pwdbuf, strlen(pwdbuf)+1+strlen(buf) > ); > + if (!pwdbuf) > + { > + // Out of memory ? > + fprintf(stderr, _("%s: could not read password > from file \"%s\": %s\n"), > + progname, pwfilename, strerror(errno)); > + exit_nicely(); > + } > + strcat( pwdbuf, buf); > + i = strlen(pwdbuf); > + } while (strlen(buf) > 0 && pwdbuf[i-1] != '\n'); > + > + while (i > 0 && (pwdbuf[i - 1] == '\r' || pwdbuf[i - 1] == > '\n')) > + pwdbuf[--i] = '\0'; > + > + if (!i) > { > fprintf(stderr, _("%s: could not read password from > file \"%s\": %s\n"), > progname, pwfilename, strerror(errno)); > @@ -1340,10 +1360,6 @@ get_set_pwd(void) > } > fclose(pwf); > > - i = strlen(pwdbuf); > - while (i > 0 && (pwdbuf[i - 1] == '\r' || pwdbuf[i - 1] == > '\n')) > - pwdbuf[--i] = '\0'; > - > pwd1 = xstrdup(pwdbuf); > > } > diff --git a/src/bin/pg_dump/pg_backup_db.c b/src/bin/pg_dump/pg_backup_db.c > index 09da892..4f64672 100644 > --- a/src/bin/pg_dump/pg_backup_db.c > +++ b/src/bin/pg_
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
On Sat, Jan 28, 2012 at 7:47 PM, Euler Taveira de Oliveira wrote: > On 28-01-2012 18:55, Andy Grimm wrote: >> It's not uniform between the client and the server, though. >> > The server doesn't impose a hard limit for password length and AFAICS it > should not because we aim for backward compatibility. > >> It sounds like you are suggesting >> that rather than increase the limit in the simple_prompt calls, you'd >> prefer to decrease the limit read from pwfile? That doesn't >> particularly help me. >> > No, I am not. So there are three concerns here: (i) increase the limit for > simple_prompt() and (ii) raise an error when we reach that limit and (iii) fix > the PasswordFromFile(). Looking at your patch, it seems to fix only (i). Sorry that it's been a couple of weeks, but I have gotten around to working on a patch that address more of these concerns. The attached patch should 1) allow arbitrary length passwords to be read from a file via initdb --pwfile 2) allow the client to accept a password of arbitrary length at the password prompt 3) allow a password of arbitrary length in a pgpass file In #2 I say "allow the client to accept", because there's a pq_getmessage call in src/backend/libpq/auth.c which limits the password message length to 1000 characters. Changing that part of the code should allow longer passwords, but there may be other lurking backend issues after that, and I'm not concerned about going beyond 1000 at this point. --Andy >> require understanding of what the real password length limit in a >> database is. >> > There is no such limit; it is stored in a text datatype. > > > -- > Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ > PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c index 99cf5b4..047b25e 100644 --- a/src/bin/initdb/initdb.c +++ b/src/bin/initdb/initdb.c @@ -1303,8 +1303,8 @@ get_set_pwd(void) /* * Read password from terminal */ - pwd1 = simple_prompt("Enter new superuser password: ", 100, false); - pwd2 = simple_prompt("Enter it again: ", 100, false); + pwd1 = simple_prompt("Enter new superuser password: ", MAX_PASSWD, false); + pwd2 = simple_prompt("Enter it again: ", MAX_PASSWD, false); if (strcmp(pwd1, pwd2) != 0) { fprintf(stderr, _("Passwords didn't match.\n")); @@ -1323,7 +1323,7 @@ get_set_pwd(void) * for now. */ FILE *pwf = fopen(pwfilename, "r"); - char pwdbuf[MAXPGPATH]; + char *pwdbuf = calloc(1,1), buf[1024]; int i; if (!pwf) @@ -1332,7 +1332,27 @@ get_set_pwd(void) progname, pwfilename, strerror(errno)); exit_nicely(); } - if (!fgets(pwdbuf, sizeof(pwdbuf), pwf)) + + do + { + if (fgets(buf, sizeof(buf), pwf) == NULL) +break; + pwdbuf = realloc( pwdbuf, strlen(pwdbuf)+1+strlen(buf) ); + if (!pwdbuf) + { +// Out of memory ? +fprintf(stderr, _("%s: could not read password from file \"%s\": %s\n"), + progname, pwfilename, strerror(errno)); +exit_nicely(); + } + strcat( pwdbuf, buf); + i = strlen(pwdbuf); + } while (strlen(buf) > 0 && pwdbuf[i-1] != '\n'); + + while (i > 0 && (pwdbuf[i - 1] == '\r' || pwdbuf[i - 1] == '\n')) + pwdbuf[--i] = '\0'; + + if (!i) { fprintf(stderr, _("%s: could not read password from file \"%s\": %s\n"), progname, pwfilename, strerror(errno)); @@ -1340,10 +1360,6 @@ get_set_pwd(void) } fclose(pwf); - i = strlen(pwdbuf); - while (i > 0 && (pwdbuf[i - 1] == '\r' || pwdbuf[i - 1] == '\n')) - pwdbuf[--i] = '\0'; - pwd1 = xstrdup(pwdbuf); } diff --git a/src/bin/pg_dump/pg_backup_db.c b/src/bin/pg_dump/pg_backup_db.c index 09da892..4f64672 100644 --- a/src/bin/pg_dump/pg_backup_db.c +++ b/src/bin/pg_dump/pg_backup_db.c @@ -143,7 +143,7 @@ _connectDB(ArchiveHandle *AH, const char *reqdb, const char *requser) if (AH->promptPassword == TRI_YES && password == NULL) { - password = simple_prompt("Password: ", 100, false); + password = simple_prompt("Password: ", MAX_PASSWD, false); if (password == NULL) die_horribly(AH, modulename, "out of memory\n"); } @@ -195,7 +195,7 @@ _connectDB(ArchiveHandle *AH, const char *reqdb, const char *requser) free(password); if (AH->promptPassword != TRI_NO) -password = simple_prompt("Password: ", 100, false); +password = simple_prompt("Password: ", MAX_PASSWD, false); else die_horribly(AH, modulename, "connection needs password\n"); @@ -242,7 +242,7 @@ ConnectDatabase(Archive *AHX, if (prompt_password == TRI_YES && password == NULL) { - password = simple_prompt("Password: ", 100, false); + password = simple_prompt("Password: ", MAX_PASSWD, false); if (password == NULL) die_horribly(AH, modulename, "out of memory\n"); } @@ -288,7 +288,7 @@ ConnectDatabase(Archive *AHX, prompt_password != TRI_NO) { PQfinish(AH->connection); - password = simple_prompt("Password: ", 100, false); + password = si
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
On Sat, Jan 28, 2012 at 5:48 PM, Alvaro Herrera wrote: > > Excerpts from Andy Grimm's message of sáb ene 28 14:32:24 -0300 2012: > >> Perhaps I should just submit the patch to pgsql-hackers ? I'm new to >> the pgsql bug interaction process, so my apologies if filing a bug was >> not the appropriate way to present the issue. I get Internal Server >> Error messages when I attempt to subscribe to any of the pgsql mailing >> lists, so this makes communication with the lists difficult. > > Err, it's not the first time I hear about this, but I haven't been able > to detect a problem anywhere. Exactly how are you trying to subscribe? Thanks for the concern, Alvaro. As it turns out, despite the 500 ISE message returned in my browser, I did receive a confirmation email and was able to subscribe to this list, so it's not entirely broken. As for how I tried to subscribe, I simply went to http://www.postgresql.org/mailpref/pgsql-bugs (which is the link provided at http://archives.postgresql.org/pgsql-bugs/ ). --Andy > -- > Álvaro Herrera > The PostgreSQL Company - Command Prompt, Inc. > PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
Excerpts from Andy Grimm's message of sáb ene 28 14:32:24 -0300 2012: > Perhaps I should just submit the patch to pgsql-hackers ? I'm new to > the pgsql bug interaction process, so my apologies if filing a bug was > not the appropriate way to present the issue. I get Internal Server > Error messages when I attempt to subscribe to any of the pgsql mailing > lists, so this makes communication with the lists difficult. Err, it's not the first time I hear about this, but I haven't been able to detect a problem anywhere. Exactly how are you trying to subscribe? -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
On 28-01-2012 18:55, Andy Grimm wrote: > It's not uniform between the client and the server, though. > The server doesn't impose a hard limit for password length and AFAICS it should not because we aim for backward compatibility. > It sounds like you are suggesting > that rather than increase the limit in the simple_prompt calls, you'd > prefer to decrease the limit read from pwfile? That doesn't > particularly help me. > No, I am not. So there are three concerns here: (i) increase the limit for simple_prompt() and (ii) raise an error when we reach that limit and (iii) fix the PasswordFromFile(). Looking at your patch, it seems to fix only (i). > require understanding of what the real password length limit in a > database is. > There is no such limit; it is stored in a text datatype. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
On Sat, Jan 28, 2012 at 1:50 PM, Euler Taveira de Oliveira wrote: > On 28-01-2012 14:32, Andy Grimm wrote: >> IMHO, there is a subtle difference here. If psql raised an error >> message on passwords exceeding 100 characters, I would understand your >> perspective, but I think that simply truncating the password and >> continuing on is a bug. I also think that hard-coding the number >> "100" in several places is simply poor practice which should be >> corrected, and that if there's good reason for that to be the password >> length limit, it should be uniformly enforced. >> > It is uniform on all of the bundled client tools. The source can always be > improved; such a constant is one of those improvements. It's not uniform between the client and the server, though. The server will allow passwords to be set which essentially make the bundled client tools useless. Even if pwfile enforced a shorter password, you'd still be able to set a long password with "alter user ...", and I have no idea what the limit is via that mechanism. >> The password is not of my choosing. It's an autogenerated sha hash of >> an RSA key, and i've simply been the key to use. >> While I agree that it's generally impractical to use such a long >> password at the command line, more than 99% of the use of this >> password is programmatic, and if I complain to the author that the >> password is too long, he'll respond "it works for me with JDBC; you >> are using broken tools. >> > So the "broken" part is the password file, right? I won't expect someone with > such a long password typing or (of course) copy/paste it, will I? Again, > patches are welcome. I guess our opinions differ here. It sounds like you are suggesting that rather than increase the limit in the simple_prompt calls, you'd prefer to decrease the limit read from pwfile? That doesn't particularly help me. >> I looked at the code before I wrote up the issue, and I have written >> and tested a patch. I've posted it here: >> >> https://bugzilla.redhat.com/attachment.cgi?id=558061 >> > Please, post a patch here, we don't follow other bug trackers. A patch is attached. I must confess that it doesn't solve the underlying problem, but merely "scratches my itch", so to speak. I simply created a constant set to 1024, since that's what initdb's pwfile option had already allowed you to set, and did not tackle the issue of what happens when the password is truncated. Dealing with truncation properly will be less trivial than this patch, and will require understanding of what the real password length limit in a database is. >> Perhaps I should just submit the patch to pgsql-hackers ? I'm new to >> the pgsql bug interaction process, so my apologies if filing a bug was >> not the appropriate way to present the issue. I get Internal Server >> Error messages when I attempt to subscribe to any of the pgsql mailing >> lists, so this makes communication with the lists difficult. >> > Bugs are tracked here but when it is not a bug but an improvement, we just > redirect this thread to -hackers. Ok, thanks for explaining. --Andy > > -- > Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ > PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento diff -urN postgresql-9.1.2/src/bin/psql/command.c postgresql-9.1.2.new/src/bin/psql/command.c --- postgresql-9.1.2/src/bin/psql/command.c 2011-12-01 16:47:20.0 -0500 +++ postgresql-9.1.2.new/src/bin/psql/command.c 2012-01-28 09:12:21.170981570 -0500 @@ -905,8 +905,8 @@ char *pw1; char *pw2; - pw1 = simple_prompt("Enter new password: ", 100, false); - pw2 = simple_prompt("Enter it again: ", 100, false); + pw1 = simple_prompt("Enter new password: ", PASSWDLEN, false); + pw2 = simple_prompt("Enter it again: ", PASSWDLEN, false); if (strcmp(pw1, pw2) != 0) { @@ -1424,15 +1424,15 @@ char *result; if (username == NULL) - result = simple_prompt("Password: ", 100, false); + result = simple_prompt("Password: ", PASSWDLEN, false); else { char *prompt_text; - prompt_text = malloc(strlen(username) + 100); - snprintf(prompt_text, strlen(username) + 100, + prompt_text = malloc(strlen(username) + PASSWDLEN); + snprintf(prompt_text, strlen(username) + PASSWDLEN, _("Password for user %s: "), username); - result = simple_prompt(prompt_text, 100, false); + result = simple_prompt(prompt_text, PASSWDLEN, false); free(prompt_text); } diff -urN postgresql-9.1.2/src/include/pg_config_manual.h postgresql-9.1.2.new/src/include/pg_config_manual.h --- postgresql-9.1.2/src/include/pg_config_manual.h 2011-12-01 16:47:20.0 -0500 +++ postgresql-9.1.2.new/src/include/pg_config_manual.h 2012-01-28 09:09:44.461992286 -0500 @@ -19,6 +19,8 @@ */ #define NAMEDATALEN 64 +#define PASSWDLEN 1024 + /* * Maximum number of arguments to a function. * diff -urN postgresql-9.1.2/src/interfaces/libpq/fe-connect.c postgresql-9.1.2.new/src/interfaces/libpq/
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
On Sat, Jan 28, 2012 at 11:55 AM, Euler Taveira de Oliveira wrote: > On 27-01-2012 23:15, agr...@gmail.com wrote: >> When psql prompts for a password, it only reads the first 100 characters of >> the password. The limit in fe-connect.c (for when .pgpass is used) is >> weirder, a seemingly arbitrary 320 bytes for all fields combined. Other >> (postgresql-jdbc, PyGreSQL, etc.) have no problem with a 512-byte password. >> It would be nice to have these limits controlled by a constant, and for the >> command to give an error or warning when a password is truncated. >> > I don't see it as a bug but a limitation. First, thank you for the quick response. IMHO, there is a subtle difference here. If psql raised an error message on passwords exceeding 100 characters, I would understand your perspective, but I think that simply truncating the password and continuing on is a bug. I also think that hard-coding the number "100" in several places is simply poor practice which should be corrected, and that if there's good reason for that to be the password length limit, it should be uniformly enforced. Regardless, of whether it's a bug or feature, though, the fixes are trivial, so I'm not sure what a strong argument _against_ the changes would be. >Why do you need such a long > password? The password is not of my choosing. It's an autogenerated sha hash of an RSA key, and i've simply been the key to use. While I agree that it's generally impractical to use such a long password at the command line, more than 99% of the use of this password is programmatic, and if I complain to the author that the password is too long, he'll respond "it works for me with JDBC; you are using broken tools. > If you are not comfortable with this reasonable limit, look at > fe-connect.c -> PasswordFromFile() and change the LINELEN. More to the point, > AFAICS all of the PostgreSQL client prompts are limited to 100 bytes (look at > simple_prompt function); letting 220 bytes for host, port, database, and user. I looked at the code before I wrote up the issue, and I have written and tested a patch. I've posted it here: https://bugzilla.redhat.com/attachment.cgi?id=558061 As you might expect, it simply defines a constant called PASSWDLEN and uses that in the calls to simple_prompt, as well as in initdb's reading of pwfile (which inexplicably uses MAXPGPATH as the maximum password length today). Perhaps I should just submit the patch to pgsql-hackers ? I'm new to the pgsql bug interaction process, so my apologies if filing a bug was not the appropriate way to present the issue. I get Internal Server Error messages when I attempt to subscribe to any of the pgsql mailing lists, so this makes communication with the lists difficult. --Andy > -- > Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ > PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
On 28-01-2012 14:32, Andy Grimm wrote: > IMHO, there is a subtle difference here. If psql raised an error > message on passwords exceeding 100 characters, I would understand your > perspective, but I think that simply truncating the password and > continuing on is a bug. I also think that hard-coding the number > "100" in several places is simply poor practice which should be > corrected, and that if there's good reason for that to be the password > length limit, it should be uniformly enforced. > It is uniform on all of the bundled client tools. The source can always be improved; such a constant is one of those improvements. > The password is not of my choosing. It's an autogenerated sha hash of > an RSA key, and i've simply been the key to use. > While I agree that it's generally impractical to use such a long > password at the command line, more than 99% of the use of this > password is programmatic, and if I complain to the author that the > password is too long, he'll respond "it works for me with JDBC; you > are using broken tools. > So the "broken" part is the password file, right? I won't expect someone with such a long password typing or (of course) copy/paste it, will I? Again, patches are welcome. > I looked at the code before I wrote up the issue, and I have written > and tested a patch. I've posted it here: > > https://bugzilla.redhat.com/attachment.cgi?id=558061 > Please, post a patch here, we don't follow other bug trackers. > Perhaps I should just submit the patch to pgsql-hackers ? I'm new to > the pgsql bug interaction process, so my apologies if filing a bug was > not the appropriate way to present the issue. I get Internal Server > Error messages when I attempt to subscribe to any of the pgsql mailing > lists, so this makes communication with the lists difficult. > Bugs are tracked here but when it is not a bug but an improvement, we just redirect this thread to -hackers. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
Euler Taveira de Oliveira writes: > I don't see it as a bug but a limitation. Why do you need such a long > password? Yeah, I think the reason we're not too consistent about this is that nobody ever imagined that limits of 100 bytes or more would pose an issue in practice. What's the use-case for passwords longer than that? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
On 27-01-2012 23:15, agr...@gmail.com wrote: > When psql prompts for a password, it only reads the first 100 characters of > the password. The limit in fe-connect.c (for when .pgpass is used) is > weirder, a seemingly arbitrary 320 bytes for all fields combined. Other > (postgresql-jdbc, PyGreSQL, etc.) have no problem with a 512-byte password. > It would be nice to have these limits controlled by a constant, and for the > command to give an error or warning when a password is truncated. > I don't see it as a bug but a limitation. Why do you need such a long password? If you are not comfortable with this reasonable limit, look at fe-connect.c -> PasswordFromFile() and change the LINELEN. More to the point, AFAICS all of the PostgreSQL client prompts are limited to 100 bytes (look at simple_prompt function); letting 220 bytes for host, port, database, and user. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6412: psql & fe-connect truncate passwords
The following bug has been logged on the website: Bug reference: 6412 Logged by: Andy Grimm Email address: agr...@gmail.com PostgreSQL version: 9.1.2 Operating system: Linux (Fedora) Description: When psql prompts for a password, it only reads the first 100 characters of the password. The limit in fe-connect.c (for when .pgpass is used) is weirder, a seemingly arbitrary 320 bytes for all fields combined. Other (postgresql-jdbc, PyGreSQL, etc.) have no problem with a 512-byte password. It would be nice to have these limits controlled by a constant, and for the command to give an error or warning when a password is truncated. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs