Date: Thu, 15 Aug 2002 16:02:16 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Maxime Henrion <mux@freebsd.org> Cc: arch@FreeBSD.org, brooks@freebsd.org Subject: Re: kernel strlcpy Message-ID: <3D5C32F8.484AECD3@mindspring.com> References: <20020815122641.B21334@Odin.AC.HMC.Edu> <20020815193028.GF14155@elvis.mu.org> <3D5C22E2.33A82B55@mindspring.com> <20020815223849.GH14155@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D5C32F8.484AECD3>