[OpenAFS] OpenAFS on OpenBSD-current (ELF)

[Brent Graveland]

Derrick J Brashear wrote:
> On Mon, 23 Jun 2003, Brent Graveland wrote:
> 
>>>Not a big deal, but make sure you test the stuff. At some point IBM did
>>>something to the kaserver which broke it for some uses due to a botched
>>>str->strn patch.
>>
>>My point exactly - I can't help but think that this is a botched
>>approach in the first place. Just because it has been done in the past,
>>I still can't happily agree to follow.
> 
> That's fine, but if it bothers you, fix it the right way, or admit that it
> doesn't bother you.

There is a third option. I can admit it bothers me, but I've got to 
decide if the cost of switching all strcat/cpy to strncat/ncpy is 
greater than the risks involved. strncat/cpy alone is no silver bullet 
as each case has to be studied individually, adding up to some major 
time investment. Since I've just recently looked slightly at openafs 
source, coupled with the fact that I'm not a secure programming expert - 
just a security conscious user, I can't properly gauge the risks.

>>Some may argue the possibility of correctly using strcat/cpy (see
>>openbsd's effort to completly remove them), but I just see overwritten
>>and truncated memory with aliases like this.
> 
> If those macros screw you, you were already screwed.

You just might not know you were screwed, or that you might be screwed 
in the future when someone exploits it. I'm not familiar with the code, 
so I can't guarantee that there is never more than 65k copied at once. I 
also can't guarantee that strings are properly null terminated 
everywhere. Because of this, I prefer strl* functions, or at least strn* 
functions.

I know I've got no right to criticize, as I've never contributed code - 
I'm just stating my views. At first glance, seeing strcpy->strncpy 
aliases makes me think of all the possible problems that can occur.

-- 
Brent Graveland
brent@graveland.net