Date: Wed, 30 Apr 2003 15:31:21 +0100 From: Paul Richards <paul@freebsd-services.com> To: Kris Kennaway <kris@obsecurity.org> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com> Subject: Re: cvs commit: src/lib/libc/gen check_utility_compat.c confstr.c un-namespace.hgethostbydns.c getnameinfo.c hesiod.c ... Message-ID: <20030430143121.GK39658@survey.codeburst.net> In-Reply-To: <20030430062647.GA82023@rot13.obsecurity.org> References: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 29, 2003 at 11:26:47PM -0700, Kris Kennaway wrote: > On Wed, Apr 30, 2003 at 12:33:03AM -0400, W. Josephson wrote: > > On Wed, Apr 30, 2003 at 12:27:22AM -0400, Daniel Eischen wrote: > > > Why can't you still do this? You just have to know the real > > > name of the function you want to override. Is malloc any > > > different than _malloc, so that you can't supply your own > > > with the correct symbol? > > > > It is just one more thing to hack around on > > every platform. I still don't understand > > why the urge to make things more complicated > > for the sake of admittedly broken software. > > Why not just fix the bug at its source rather > > than making life more difficult for stuff that > > is written correctly? > > Because the source is not always available. Fortunately, for qpopper > it is, but as Jacques stated in another message there is a chance that > other binary applications also do this. Hiding our libc implementation is the wrong approach here. I think the strlcpy hiding should be taken out. Your example of binary only applications actually shows exactly why this approach is wrong since if the application deliberately tries to override the libc version then it won't work. 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. -- Paul Richards
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030430143121.GK39658>