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 по дате отправления:

Предыдущее
От: Yui Hiroaki
Дата:
Сообщение: compact database
Следующее
От: Chris Browne
Дата:
Сообщение: Re: plans for bitmap indexes?