From owner-freebsd-arch Thu Aug 15 16: 3:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2B6F37B400; Thu, 15 Aug 2002 16:03:40 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6093A43E6A; Thu, 15 Aug 2002 16:03:40 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.131.82.dial1.sanjose1.level3.net ([209.245.131.82] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fTeN-0002jJ-00; Thu, 15 Aug 2002 16:03:34 -0700 Message-ID: <3D5C32F8.484AECD3@mindspring.com> Date: Thu, 15 Aug 2002 16:02:16 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxime Henrion Cc: arch@FreeBSD.org, brooks@freebsd.org Subject: Re: kernel strlcpy References: <20020815122641.B21334@Odin.AC.HMC.Edu> <20020815193028.GF14155@elvis.mu.org> <3D5C22E2.33A82B55@mindspring.com> <20020815223849.GH14155@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxime Henrion wrote: [ ... adding strlcpy ... ] > > No, please. It encourages idiots to do string processing in > > the kernel, when you should be carrying around this crap in > > user space, instead. > > It doesn't encourage people to do string processing in the kernel any > more, since we already have strcpy() and strncpy(). Those should be removed in any case, if strlcpy will so magically save us from "all those" kernel buffer overflow exploits out there, and we should change libc so that the compiler whines "This program uses strcpy, which is unsafe". Or maybe just "This program was written by a someone other than me, which is unsafe". 8-). > Yes, generally speaking, string processing in the kernel is bad, > but using str?cpy() is not necessarily bad. Whatever you do, we > have some information represented by strings in the kernel, and we > sometimes need to copy these strings. We're not parsing files here. > :-) UFS Quotas. We *are* parsing files here. And we're parsing command line options to "mount". And names of things for /etc/exports. We started down this slippery slope years ago, and haven't bothered looking back since. > Going against strlcpy() doesn't help at all here; everywhere we need to > copy strings we're forced to work around strncpy() which is a broken > interface, and there is still the risk someone will write code using > strncpy() without taking care of that problem, thus creating a possible > security flaw. Gug. Might as well cvs import OpenBSD and be done with it. 8^P. How about deleting strncpy() when you import strlcpy()? > I tend to agree; I think there are cases of string manipulation in the > kernel that would be avoided. But as you already said, there *are* > valid uses for these functions. That's why we shouldn't make life so > hard for these subsystems. Forcing them to use strncpy() while they > could use strlcpy() doesn't make people more conscious of the problems > we have with other subsystems using string manipulation when they > shouldn't. It just makes programming harder for the valid cases. I think it encourages "more of the same", by example. In any case, if this is supposed to replace strncpy, it should, in fact, replace it, not add yet another function. "The wonderful thing about standards is there are so many to choose from" - Andy Tannenbaum -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message