Re: [Devil-linux-develop] iptraf and OpenVPN tun interfaces

[Andrzej O. <an...@ma...>]

Heiko Zuerker wrote:
> Any issues with this patch being present in the 32 bit version?

Generally strcpy() function should not to be used in this manner as in ltrim() 
in ifaces.c of iptraf package, because standard specification of strcpy says:

> char * strcpy ( char * destination, const char * source );
> 
> Copies the C string pointed by source into the array
> pointed by destination, including the terminating null character.
> 
> To avoid overflows, the size of the array pointed by destination
> shall be long enough to contain the same C string as source
> (including the terminating null character),
> and should not overlap in memory with source.
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

But effects depends on implementation of strcpy (maybe of glibc version). 
Quite simple task of copying string in our glibc is now the following:

> /* Copy SRC to DEST.  */
> char *
> strcpy (dest, src)
>      char *dest;
>      const char *src;
> {
>   reg_char c;
>   char *__unbounded s = (char *__unbounded) CHECK_BOUNDS_LOW (src);
>   const ptrdiff_t off = CHECK_BOUNDS_LOW (dest) - s - 1;
>   size_t n;
> 
>   do
>     {
>       c = *s++;
>       s[off] = c;
>     }
>   while (c != '\0');
> 
>   n = s - src;
>   (void) CHECK_BOUNDS_HIGH (src + n);
>   (void) CHECK_BOUNDS_HIGH (dest + n);
> 
>   return dest;
> }

so is not simple (but maybe fast) and I'm not sure, what is doing for above 
program our compiler and it's code generator. How long is reg_char type, how 
is copied to memory etc.? For this knowledge, there is need to read many 
sources. But if I will even analyse generated code, this can change with new 
version of glibc or compiler. All, because standard says: "destination string 
should not overlap in memory with source" and this does not depends on 32/64 bits.

I find this problem testing my sorting patch, when string |  eth0| grabbed 
from /proc/net/dev after ltrim became |e0h0| and this interface name is in 
interface list in iptraf. As for now 32-bit compiled strcpy is not doing this 
strange things. At least in my tests. But the 64-bit strcpy does so.

Interface list in iptraf is used to construct menu of interfaces and for 
general statistics, but each interface on list is checked for operativity and 
removed from list, if is not operative, so affected interface "e0h0" is 
removed as non-operative. When we select general statistics, network packets 
are catched and increments counter on this list, but if interface pointed by 
packet is not found on this list (i.e. because name was broken), interface is 
added to list from packet at list end. So this error is near invisible. But as 
effect, starting interface menu can be without affected interface name.

Ofcourse there can be many other side effects.

But in ltrim() we not need to shift this string. Is sufficient to return 
address pointing to start of interface name in original string.

I think: it is better to apply always this patch, as side effects of this bug 
are unpredictable.

Regards

-- 
Andrzej Odyniec