From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27899 invoked by alias); 1 Nov 2005 20:11:57 -0000 Mailing-List: contact insight-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sourceware.org Received: (qmail 27864 invoked by uid 22791); 1 Nov 2005 20:11:53 -0000 Received: from shadbolt.decadentplace.org.uk (HELO shadbolt.decadentplace.org.uk) (88.96.1.122) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 01 Nov 2005 20:11:53 +0000 Received: from [192.168.4.103] (helo=localhost) by shadbolt.decadentplace.org.uk with esmtp (Exim 4.50) id 1EX2U2-0006YP-FS; Tue, 01 Nov 2005 20:11:50 +0000 Received: from womble by localhost with local (Exim 4.50) id 1EX2Tn-0002JE-B5; Tue, 01 Nov 2005 20:11:35 +0000 Subject: RE: Possible security flaw in Insight From: Ben Hutchings To: Dave Korn Cc: insight@sources.redhat.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rKPT6WRUpCMcS9v2/HoZ" Date: Tue, 01 Nov 2005 20:11:00 -0000 Message-Id: <1130875894.1980.55.camel@localhost> Mime-Version: 1.0 X-SW-Source: 2005-q4/txt/msg00008.txt.bz2 --=-rKPT6WRUpCMcS9v2/HoZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 1985 Dave Korn wrote: > Ben Hutchings wrote: =20 > > In some versions of Tcl (8.4.2 to 8.5a2 inclusive), the dimension of the > > name field is MAXNAMLEN+1, not PATH_MAX+1. >=20 > The code I quoted was from /src, which hasn't had a new version merged = in > from upstream recently and is still on 8.4.1. Good; I've updated the advisory to state that there is no problem when using the included version of Tcl. =20 > > > >> I'm with Zaraza (sp?) on this one. What's wrong with statically > >> sizing it to NAME_MAX+1, in accordance with the demands of the posix > >> spec? =20 > >=20 > > NAME_MAX isn't required to be defined (and MAXNAMLEN isn't even > > mentioned by POSIX, though it is equivalent on many systems).=20=20 >=20 > Oh well, autoconf can help with that, as could falling back to PATH_MAX= if > it exists. In practice, it doesn't seem to really be an issue: the use of > PATH_MAX in that structure is unconditional and in fact not autoconfiscat= ed, > and nobody has reported that they've had trouble building for lack of it. While this seems to me to be a poor way of determining the buffer size, in practice it is likely to be safe. > > GNU/Hurd > > doesn't define it, for example, because there is no practical limit on > > name lengths there. >=20 > Umm, then surely GNU/Hurd is insane and cannot be used because there is= no > way to ever know how much space to allocate for a dirent? No, that's what pathconf is for. Most systems that define NAME_MAX are not POSIX-compliant in this respect because they support filesystems that have name length limits differing from whatever value they specify. Please see the sample code for a dirent_buf_size function in revision 2 of the advisory at . Ben. --=20 Ben Hutchings When you say `I wrote a program that crashed Windows', people just stare ... and say `Hey, I got those with the system, *for free*'. - Linus Torvalds --=-rKPT6WRUpCMcS9v2/HoZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDZ8v279ZNCRIGYgcRAkBMAKDgRV2yIxBr/3/DLTk3l3/fOYL0lwCgsUgq rKUUrz8mtN+5Lf4J+rc1txo= =DBVc -----END PGP SIGNATURE----- --=-rKPT6WRUpCMcS9v2/HoZ--