Improving name-truncation detection

[jw schultz]

On Mon, Jan 19, 2004 at 05:44:20PM -0800, Wayne Davison wrote:
> On Mon, Jan 19, 2004 at 02:39:56PM -0800, jw schultz wrote:
> > If we are going to vet the path name for overflow (a good idea) lets
> > do it once, explicitly, as we receive it instead of having tests
> > scattered throughout the code.
> 
> Yeah, good idea.
> 
> > When all you are doing is concatinating a couple of strings snprintf
> > is overkill
> 
> I forgot how slow snprintf() is (it's nearly three times slower than
> other methods of concatenation).  There are a few places in the code
> that are already using it (such as the backup code), which we should
> change in light of this.
> 
> A bigger problem, though, is that the current f_name_to() code doesn't
> handle an overflow properly:  if "bsize - off" is negative, the value

If f_name_to were a generalized function i'd agree.  It
isn't  It concatenates a pair of fixed strings that can
only produce a negative "bsize - off" if we don't test the
values on receipt and have a malicious client.

> turns unsigned once it gets to the strlcpy() function.  Ouch!  Using
> successive strlcat() calls would be safe, but using a strlcat() call
> after a strlcpy() of just a couple hundred bytes has about a 50% speed
> penalty compared to following it with an offset strlcpy() call.

Cache misses caused by rescanning the destination to find
the terminator and length.  (It takes a few hundred bytes
before you are likely to see L1 misses.)  That is why we use
stacked strlcpy.

> I wrote a function that will let us concatenate values together safely
> without a speed penalty.  Encapsulating it in a function ensures that we
> don't have to have a series of "if (no overflow) x = strlcpy(...);"
> calls every time we concatenate something.  It also ensures that we do
> it the safe way everywhere.
> 
> The function is called with any number of character strings, like this:
> 
>     total_len = stringjoin(dest, sizeof dest, s1, s2, s3, NULL);
> 
> I'll append my util.c patch to this email.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt