Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname
От | Peter Davie |
---|---|
Тема | Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname |
Дата | |
Msg-id | 41678925.5020605@relevance.com.au обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi Guys,<br /><br /><pre wrap="">Please refer to <a class="moz-txt-link-rfc2396E" href="http://www.opengroup.org/onlinepubs/009695399/functions/getpwuid.html"><http://www.opengroup.org/onlinepubs/009695399/functions/getpwuid.html></a>: "[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</pre><br /> Tom Lane wrote:<br /><blockquote cite="mid24145.1097298418@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="">Whatdo 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. </pre></blockquote><pre wrap=""> 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 </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>
В списке pgsql-hackers по дате отправления: