Date: Thu, 15 Aug 2002 17:22:40 -0700 From: Maxime Henrion <mux@freebsd.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: arch@freebsd.org, brooks@freebsd.org Subject: Re: kernel strlcpy Message-ID: <20020816002240.GI14155@elvis.mu.org> In-Reply-To: <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> <3D5C32F8.484AECD3@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > 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". It's not that easy, as you already admitted, there are valid cases for their use. So we can't just remove them. > 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. Yes, that's awful. But this is an argument against string processing in the kernel, not against strlcpy(). > > 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()? That would require that the person who does the import also converts all consumers at the same time. Maybe that extra pain is not necessary, and we could do the transition in a more smooth way. Of course, then there is the risk that people will forget about that and live with both functions forever. > > 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. I agree, but as I said, maybe it's not worth doing all that at once. Anyways, we are now discussing how it should be done, and not if it should be done. Let's not go off-topic. Cheers, Maxime 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?20020816002240.GI14155>