Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 May 2003 15:46:00 +0100
From:      Paul Richards <paul@freebsd-services.com>
To:        "Jacques A. Vidrine" <nectar@FreeBSD.org>, freebsd-arch@FreeBSD.org
Subject:    Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...)
Message-ID:  <20030501144600.GC1869@survey.codeburst.net>
In-Reply-To: <20030501143032.GA34163@madman.celabo.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> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 01, 2003 at 09:30:32AM -0500, Jacques A. Vidrine wrote:
> On Thu, May 01, 2003 at 03:02:55PM +0100, Paul Richards wrote:
> > On Wed, Apr 30, 2003 at 11:41:35AM -0500, Jacques A. Vidrine wrote:
> > > [Trimmed cc:list;  moving to freebsd-arch]
> > > 
> > > 
> > > First, has something been broken by making strlcpy/strlcat into a weak
> > > reference?
> > 
> > Yes, deliberately overloading it from an application now no longer
> > works.
> 
> Give me a break.  Good, it should not work by accident.  An
> application might define strlcpy for its own use, but we should NEVER
> use the application's strlcpy. [1]

An application doesn't have any business defining a strlcpy, since
str* is reserved.  The qpopper application is just broken and we
shouldn't be "fixing" our libc to work around that.

The only time you're likely to do something like this is if you're
deliberately overriding the "official" implementation of these
functions because you're instrumenting or something of a similar
nature.

> > What really concerns me though, is that behaviour is only defined
> > for 2 functions.
> 
> No, it is done for some 150+ functions.  If the technique didn't have

150+? I must have missed that in the commit and subsequent discussion.

> a certain distasteful side-effect when used en masse, I would push
> for covering almost all of the other symbols libc exports.  (If an
> application defines `strcpy', should we use that from within libc?)
> But until a better technique arrives, I am happy to apply it a little
> less liberally.

POLA suggests yes, since that's how it's always worked and there
are a category of applications that rely on this behaviour (which
would work on other platforms but not FreeBSD and for a reason that
would be very hard to determine). Just because qpopper is broken
doesn't mean that all applications should now be prohibited from
exploiting this technique.

> > The implementation of FreeBSD should be what's correct, we shouldn't
> > fudge things to accomodate bad packages, fix the problem where the
> > problem really exists.
> 
> Obviously, I don't see it the same way you do.  Calling the
> application's strlcpy in order to implement some internal libc
> function is not ``what's correct'', regardless of whether the
> application is buggy or perfect.

Hmm, perhaps a more correct implementation of our libc would not
use the exported interface to implement the exported interface
(thinking aloud).

i.e. there'd be a _strlcpy that strlcpy was just a wrapper for
and internally the _strlcpy would be used.

-- 
Paul Richards



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501144600.GC1869>