Date: Wed, 30 Apr 2003 10:27:08 -0500 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: Paul Richards <paul@freebsd-services.com>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: cvs commit: src/lib/libc/gen check_utility_compat.c confstr.c un-namespace.hgethostbydns.c getnameinfo.c hesiod.c ... Message-ID: <20030430152708.GA26216@madman.celabo.org> In-Reply-To: <20030430144149.GA7786@dragon.nuxi.com> <20030430143121.GK39658@survey.codeburst.net> References: <20030430002014.GA1190@dragon.nuxi.com> <xzpptn4rfww.fsf@flood.ping.uio.no> <20030430004907.GA32349@mero.morphisms.net> <20030430031856.GA20258@madman.celabo.org> <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <Pine.GSO.4.10.10304300024280.1846-100000@pcnet1.pcnet.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 30, 2003 at 03:31:21PM +0100, Paul Richards wrote: > If it's a bug in the application then it's a bug in the application and > either that gets fixed in the source or you complain to the vendor.Messing > with the exported symbols from libc doesn't seem like the right solution > to me. On Wed, Apr 30, 2003 at 07:41:49AM -0700, David O'Brien wrote: > Why is it "too risky"? If the software is setuid, LD_LIBRARY_PATH and > LD_PRELOAD won't work. If it is run with normal user-level privs, It is `too risky' because it can introduce bugs into applications (including applications that run with increased privileges). qpopauth's strlcpy worked just fine for how qpopauth used it. In some sense, it is not really a bug for qpopper [1]. However, it _is_ a bug for e.g. getpwent() to use qpopper's strlcpy. We have no business exporting symbols from libc that are not described by any standard. We have no business assuming that if an application defines a function called `strlcpy' that it resembles, in intent or in actual implementation, our own strlcpy. What if e.g. an old text-processing application had it's own implementation of fixed-length strings. Maybe `strlcpy' is part of that implementation, and has different arguments and semantics and return value from our strlcpy. Is it a bug in that application if it cannot use parts of libc because of this? No. It is a bug in our libc. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se [1] This is only for purposes of discussion. I consider it an actual bug because the comments in the code do not match the implementation.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030430152708.GA26216>