Date: Wed, 30 Apr 2003 07:41:49 -0700 From: "David O'Brien" <dev-null@NUXI.com> To: "Jacques A. Vidrine" <nectar@FreeBSD.org> Cc: Dag-Erling Smorgrav <des@ofug.org> Subject: Re: cvs commit: src/lib/libc/gen check_utility_compat.c confstr.c fmtmsg.c getgrent.c getpwent.c src/lib/libc/include namespace.h un-namespace.h src/lib/libc/locale setlocale.c src/lib/libc/net getaddrinfo.c gethostbydns.c getnameinfo.c hesiod.c ... Message-ID: <20030430144149.GA7786@dragon.nuxi.com> In-Reply-To: <20030430031856.GA20258@madman.celabo.org> References: <200304292113.h3TLDoGF072965@repoman.freebsd.org> <xzp65oxrn3e.fsf@flood.ping.uio.no> <20030430002014.GA1190@dragon.nuxi.com> <xzpptn4rfww.fsf@flood.ping.uio.no> <20030430004907.GA32349@mero.morphisms.net> <20030430031856.GA20258@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 29, 2003 at 10:18:56PM -0500, Jacques A. Vidrine wrote: > I chose to hide strlcpy/strlcat anyway because I am far from certain > that qpopper is the only application supplying its own (working or > not) implementations. We don't want to call those from within libc, > ever. It is too risky. 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, well... there are *plenty* of ways to add "risk". Foot... gun... pull trigger... It is not our place or responsibility to go to these lengths to protect users. I strongly don't want to see a lot of libc function hiding and alternate symbols. -- -- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030430144149.GA7786>