Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Davie <Peter(dot)Davie(at)relevance(dot)com(dot)au>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname
Date: 2004-10-09 04:14:48
Message-ID: 200410090414.i994Emb03700@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

---------------------------------------------------------------------------

Peter Davie wrote:
> Hi Bruce,
>
> (As I explained to Tom, the situation for me is difficult:
>
> How can I "fix the app" when the application is a commercial binary which
> provides no means of configuring the stack size for the thread? I have
> been successfully using PostgreSQL with this application since v7.1 and
> have a happy customer with it. Now, upgrading the database to v7.4.5
> which is strongly recommended by the development group (due to potentially
> serious bugs) means that the application no longer works!
> )
>
> Since then I have done some background reading
> <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.
>
> Thanks
> Peter
>
> > Tom Lane wrote:
> >> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> > Oops. Yep, that is sloppy programming on our part, perhaps my part if
> >> I
> >> > added those. Anyway, patch attached and applied. I used the proper
> >> > struct sizes instead of BUFSIZ.
> >>
> >> You just broke it.
> >>
> >> Those buffers are not used to hold struct passwd's, but to hold
> >> multiple character strings to which the struct passwd will point;
> >> any one of which could be long, but particularly the home directory
> >> path.
> >>
> >> My man page for getpwuid_r says that the minimum recommended buffer size
> >> is 1024.
> >>
> >> > This will be in 8.0.
> >>
> >> I think we should revert it entirely. A small buffer size risks
> >> breaking things unnecessarily, and as I replied earlier, the request
> >> to make libpq run in a less-than-8K stack is not reasonable anyway.
> >
> > Reverted. I forgot about the requirement to store pointers used by the
> > structure. I knew that when doing the thread patches but forgot about
> > it.
> >
> > --
> > Bruce Momjian | http://candle.pha.pa.us
> > pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> > + If your life is a hard drive, | 13 Roberts Road
> > + Christ can be your backup. | Newtown Square, Pennsylvania
> > 19073
> >
>
>
> --
> Relevance Phone: +61 2 6241 6400
> A.B.N. 86 063 403 690 Fax: +61 2 6241 6422
> Unit 11, Mitchell Commercial Ctr, E-mail: peter(dot)davie(at)relevance(dot)com(dot)au
> cnr Brookes and Heffernan Sts., Web: http://www.relevance.com.au
> Mitchell ACT 2911
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-10-09 04:35:05 Re: Inability to cast regclass is too restrictive
Previous Message Bruce Momjian 2004-10-09 04:04:29 Re: [PATCHES] Win32 Version numbering patch