Re: BUG #6412: psql & fe-connect truncate passwords

From: Andy Grimm <agrimm(at)gmail(dot)com>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #6412: psql & fe-connect truncate passwords
Date: 2012-01-28 21:55:20
Message-ID: CAEoAmOqZd6Ey6Egx3n_BMOzhHxdvWO2rE=6Z9zkt+U3D9kvgbA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Jan 28, 2012 at 1:50 PM, Euler Taveira de Oliveira
<euler(at)timbira(dot)com> 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

Attachment Content-Type Size
postgresql-passwdlen.patch text/x-patch 3.1 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2012-01-28 22:34:23 Re: BUG #6200: standby bad memory allocations on SELECT
Previous Message Michael Brauwerman 2012-01-28 21:34:30 Re: BUG #6200: standby bad memory allocations on SELECT