Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname

From: Peter Davie <Peter(dot)Davie(at)relevance(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname
Date: 2004-10-09 06:45:57
Message-ID: 41678925.5020605@relevance.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Guys,

Please refer to <http://www.opengroup.org/onlinepubs/009695399/functions/getpwuid.html>:

"[TSF] The getpwuid_r() function shall update the passwd structure pointed
to by pwd and store a pointer to that structure at the location pointed to
by result. The structure shall contain an entry from the user database
with a matching uid. Storage referenced by the structure is allocated from
the memory provided with the buffer parameter, which is bufsize bytes in
size. The maximum size needed for this buffer can be determined with the
{_SC_GETPW_R_SIZE_MAX} sysconf() parameter. A NULL pointer shall be
returned at the location pointed to by result on error or if the requested
entry is not found."

On Tru64 UNIX, sysconf(_SC_GETPW_R_SIZE_MAX) returns 1024.

When I modified the source, I punted a value of 1024 and this has worked flawlessly in an intensive environment (numerous inserts per minute, sustained) for a few weeks now.

Thanks
Peter

Tom Lane wrote:

>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>
>
>>What do people think about using (sizeof(struct passwd) + BUFLEN/2) rather
>>than BUFLEN for the getpwuid_r size, or (sizeof(struct passwd) + MAXPGPATH*2)?
>>That would reduce the stack requirements and still be safe, I think.
>>
>>
>
>Why bother?
>
>Peter did not say what his closed-source app could tolerate. Without
>that knowledge you're just flying blind about fixing his problem.
>I see no reason to risk creating buffer-overflow issues for other people
>in order to make a maybe-or-maybe-not improvement for one rather broken
>closed-source app...
>
> regards, tom lane
>
>

--
Relevance... because results count

Relevance Phone: +61 (0)2 6241 6400
A.B.N. 86 063 403 690 Fax: +61 (0)2 6241 6422
Unit 11, Mitchell Commercial Centre, Mobile: +61 (0)417 265 175
cnr Brookes and Heffernan Sts., E-mail: peter(dot)davie(at)relevance(dot)com(dot)au
Mitchell ACT 2911 Web: http://www.relevance.com.au

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message G Reina 2004-10-09 09:03:09 SSL with Beta3 - "could not load root certificate file"
Previous Message Oliver Elphick 2004-10-09 06:18:56 Re: Inability to cast regclass is too restrictive