Thread: Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname
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 (numerousinserts per minute, sustained) for a few weeks now. > > Thanks > Peter > > > Tom Lane wrote: > > >Bruce Momjian <pgman@candle.pha.pa.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.davie@relevance.com.au > Mitchell ACT 2911 Web: http://www.relevance.com.au > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.
>> On Tru64 UNIX, sysconf(_SC_GETPW_R_SIZE_MAX) returns 1024.
I'd be more impressed by this line of reasoning if _SC_GETPW_R_SIZE_MAX
were defined on more than one of the platforms I use...
regards, tom lane
Hi Tom,<br /><br /> How many of these platforms you use are POSIX-compliant? This information came from the POSIX web
site(NOT THE DIGITAL/COMPAQ/HP/... WEBSITE). Sysconf(_SC_GETPW_R_SIZE_MAX) is supported by Solaris 2.5, SCO UNIX
(circa1999!), Digital UNIX/Compaq Tru64 UNIX, FreeBSD, AIX, HP-UX, and probably many more.<br /><br /> Maybe the
non-compliantplatforms should be catered for as "legacy" with support code in the "ports" area, and those that do
adhereto open standards can be accommodated without breaking existing production applications.<br /><br /> Thanks<br />
Peter<br/><br /> Tom Lane wrote:<br /><blockquote cite="mid5074.1097364232@sss.pgh.pa.us" type="cite"><pre
wrap="">BruceMomjian <a class="moz-txt-link-rfc2396E"
href="mailto:pgman@candle.pha.pa.us"><pgman@candle.pha.pa.us></a>writes: </pre><blockquote type="cite"><pre
wrap="">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. </pre></blockquote><pre wrap="">
</pre><blockquotetype="cite"><blockquote type="cite"><pre wrap="">On Tru64 UNIX, sysconf(_SC_GETPW_R_SIZE_MAX) returns
1024. </pre></blockquote></blockquote><pre wrap="">
I'd be more impressed by this line of reasoning if _SC_GETPW_R_SIZE_MAX
were defined on more than one of the platforms I use...
regards, tom lane </pre></blockquote><br /><br /><pre class="moz-signature" cols="72">--
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: <a class="moz-txt-link-abbreviated"
href="mailto:peter.davie@relevance.com.au">peter.davie@relevance.com.au</a>
Mitchell ACT 2911 Web: <a class="moz-txt-link-freetext"
href="http://www.relevance.com.au">http://www.relevance.com.au</a></pre>
One idea would be to use malloc() to allocate storage for the thread-safe buffers when compiled with thread-safety, rather than using the stack. --------------------------------------------------------------------------- Peter Davie wrote: > Hi Tom, > > How many of these platforms you use are POSIX-compliant? This > information came from the POSIX web site (NOT THE DIGITAL/COMPAQ/HP/... > WEBSITE). Sysconf(_SC_GETPW_R_SIZE_MAX) is supported by Solaris 2.5, > SCO UNIX (circa 1999!), Digital UNIX/Compaq Tru64 UNIX, FreeBSD, AIX, > HP-UX, and probably many more. > > Maybe the non-compliant platforms should be catered for as "legacy" with > support code in the "ports" area, and those that do adhere to open > standards can be accommodated without breaking existing production > applications. > > Thanks > Peter > > Tom Lane wrote: > > >Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > > >>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. > >> > >> > > > > > > > >>>On Tru64 UNIX, sysconf(_SC_GETPW_R_SIZE_MAX) returns 1024. > >>> > >>> > > > >I'd be more impressed by this line of reasoning if _SC_GETPW_R_SIZE_MAX > >were defined on more than one of the platforms I use... > > > > 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.davie@relevance.com.au > Mitchell ACT 2911 Web: http://www.relevance.com.au > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Hi Bruce,<br /><br /> That would work!<br /><br /> Thanks<br /> Peter<br /><br /> Bruce Momjian wrote: <blockquote
cite="mid200410142030.i9EKU2421482@candle.pha.pa.us"type="cite"><pre wrap="">One idea would be to use malloc() to
allocatestorage for the
thread-safe buffers when compiled with thread-safety, rather than using
the stack.
---------------------------------------------------------------------------
Peter Davie wrote: </pre><blockquote type="cite"><pre wrap="">Hi Tom,
How many of these platforms you use are POSIX-compliant? This
information came from the POSIX web site (NOT THE DIGITAL/COMPAQ/HP/...
WEBSITE). Sysconf(_SC_GETPW_R_SIZE_MAX) is supported by Solaris 2.5,
SCO UNIX (circa 1999!), Digital UNIX/Compaq Tru64 UNIX, FreeBSD, AIX,
HP-UX, and probably many more.
Maybe the non-compliant platforms should be catered for as "legacy" with
support code in the "ports" area, and those that do adhere to open
standards can be accommodated without breaking existing production
applications.
Thanks
Peter
Tom Lane wrote:
</pre><blockquote type="cite"><pre wrap="">Bruce Momjian <a class="moz-txt-link-rfc2396E"
href="mailto:pgman@candle.pha.pa.us"><pgman@candle.pha.pa.us></a>writes:
</pre><blockquote type="cite"><pre wrap="">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.
</pre></blockquote><pre wrap="">
</pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">On Tru64 UNIX, sysconf(_SC_GETPW_R_SIZE_MAX)
returns1024.
</pre></blockquote></blockquote><pre wrap="">I'd be more impressed by this line of reasoning if
_SC_GETPW_R_SIZE_MAX
were defined on more than one of the platforms I use...
regards, tom lane
</pre></blockquote><pre wrap="">
-- 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: <a class="moz-txt-link-abbreviated"
href="mailto:peter.davie@relevance.com.au">peter.davie@relevance.com.au</a>
Mitchell ACT 2911 Web: <a class="moz-txt-link-freetext"
href="http://www.relevance.com.au">http://www.relevance.com.au</a>
</pre></blockquote><pre wrap=""> </pre></blockquote><br /><br /><pre class="moz-signature" cols="72">--
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: <a class="moz-txt-link-abbreviated"
href="mailto:peter.davie@relevance.com.au">peter.davie@relevance.com.au</a>
Mitchell ACT 2911 Web: <a class="moz-txt-link-freetext"
href="http://www.relevance.com.au">http://www.relevance.com.au</a></pre>