Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname
Date
Msg-id 200410092209.i99M9ZZ23547@candle.pha.pa.us
Whole thread Raw
Responses Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Security implications of config-file-location patch
Next
From: Tom Lane
Date:
Subject: Re: Security implications of config-file-location patch