Re: fix for palloc() of user-supplied length

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Serguei Mokhov <mokhov(at)cs(dot)concordia(dot)ca>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: fix for palloc() of user-supplied length
Date: 2002-08-30 05:24:41
Message-ID: 27069.1030685081@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Neil Conway <neilc(at)samurai(dot)com> writes:
> (2) The length supplied by the user is completely ignored by
> the code, and it simply reads the input until it sees a
> NULL terminator (read the comments in the code about 10
> lines down.) Therefore, any sanity checking on the length
> specified by the user is a waste of time.

Agreed; the fact that the protocol requires a length word at all is just
a hangover from the past. We can read the length word and forget it.

I wonder though if it'd be worthwhile to limit the length of the string
that we are willing to read from the client in the second step. We are
at this point dealing with an unauthenticated user, so we should be
untrusting. And I think Sir Mordred has a point: forcing a backend to
allocate a lot of memory can be a form of DoS attack.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mario Weilguni 2002-08-30 05:59:40 Re: C vs. C++ contributions
Previous Message Neil Conway 2002-08-30 05:10:29 Re: fix for palloc() of user-supplied length

Browse pgsql-patches by date

  From Date Subject
Next Message Manfred Koizar 2002-08-30 11:22:32 Slightly reduce BufMgrLock contention
Previous Message Tom Lane 2002-08-30 05:14:17 Re: revised patch for PL/PgSQL table functions