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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Davie <Peter(dot)Davie(at)relevance(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(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 22:09:35
Message-ID: 200410092209.i99M9ZZ23547@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


OK, we got a report. I just thinkg 8192 is excessive for that
structure, and if someone is having a problem, others might as well.

---------------------------------------------------------------------------

Peter Davie wrote:
> 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
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-10-09 23:05:37 Re: First set of OSDL Shared Mem scalability results, some wierdness ...
Previous Message Bruce Momjian 2004-10-09 21:56:21 Re: Security implications of config-file-location patch