Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<3E137C1C.50804@ece.gatech.edu>
Date:	Wed, 01 Jan 2003 18:39:08 -0500
From:	Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language:	en-us, en
MIME-Version:	1.0
To:	"Steven O'Brien" <steven DOT obrien2 AT ntlworld DOT com>, cygwin AT cygwin DOT com
Subject:	Re: Heads up: *possible* bug in cygwin
References:	<20030101100510 DOT 5b5b7f3f DOT steven DOT obrien2 AT ntlworld DOT com>

Steven O'Brien wrote:
> Hi
> I found a possible glib buffer overflow that is cygwin-specific (due to
> a bug in cygwin perhaps?) that I worked around when porting glib-1.2.10
> to cygwin. Maybe this is still a problem in glib-2.0.x

> From (hazy) memory, the buffer is 64 bytes, so if your /etc/passwd entry
> has more than 64 chars (quite possible if you are using ntsec) then
> memory gets trashed.
> 
> My patch works around this problem by allocating a buffer of 1024 bytes
> for cygwin. I think I got this value by reading the cygwin dll source to
> find a real upper bound, but it was a long time ago so this needs
> checking. 

I saw this...it's probably a decent workaround, but hasn't yet been 
accepted into current glib source AFAICT --- glib-2.2.0 still uses a 64 
byte buffer for reading pw entries.  But that's not where the segfault 
is happening in my case (as my earlier message showed).

> Of course a real fix is required to sysconf() /  getpwuid_r() in cygwin,

I'm not sure about that -- is there some POSIX limitation on the number 
of bytes that getpwuid_r() is allowed to return?  I think existing code 
that hardcodes a 64 byte limit is just using that magic number because 
it "works on linux" (and hpux/solaris/etc)

> but to test this theory you could borrow the fix from my glib patch and
> try it on glib 2.0.x

Most of the patches I *did* use were from your 1.2.x work. :-)

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -