Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname
От | Bruce Momjian |
---|---|
Тема | Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname |
Дата | |
Msg-id | 200410092209.i99M9ZZ23547@candle.pha.pa.us обсуждение исходный текст |
Ответы |
Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname
|
Список | 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 (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
В списке pgsql-hackers по дате отправления: