![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
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 |
#3
| ||||
| ||||
|
|
On 27-01-2012 23:15, agrimm (AT) gmail (DOT) com wrote: When psql prompts for a password, it only reads the first 100 charactersof 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 |
#4
| |||
| |||
|
|
I don't see it as a bug but a limitation. Why do you need such a long password? |
#5
| ||||
| ||||
|
|
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 |
|
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 |
|
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 |
#6
| |||
| |||
|
|
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. |
#7
| |||
| |||
|
|
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 <alvherre (AT) commandprompt (DOT) com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support |
#8
| |||
| |||
|
|
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 |
|
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 |
|
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. |
![]() |
| Thread Tools | |
| Display Modes | |
| |