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
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 |