ssp, __strcpy_ck: just to be sure

[tlaronde%polynum.com@localhost]

I was a bit puzzled about the behavior of __strcpy_ck and, more specially,
__ssp_overlap and I think I got the explanation with ssp(3) man page but
I'd like to check that I did get the point.

Context: I upgraded to 9.1 and when compiling I use -D_FORTIFY_SOURCE=2.

One program that used to run properly then crashed. Looking at the
coredump, it indicated a strcpy() call as the offending call.

Editing the C file, I first saw that I have added a comment about the
buffers being fixed size and no bound check being made so I started by
reviewing the (historical) file and switching to dynamic allocation and
bound checks.

Recompiled, the program worked.

But then I realized that I have not changed the offending line: the
strcpy() call since there was no overflow problem: it was doing inplace
rewrite, suppressing a prefix (doing basename(1) essentially).

That's when I saw that the problem was the call to __strcpy_ck and
__ssp_overlap, and the addresses, by the very purpose of the code, were
overlapping. So I changed this to direct recopy with pointers
manipulation avoiding strcpy(3).

But the lesson was that the __ssp_overlap succeeded to pinpoint the
overlap with the buffer declared as an (fixed size) array but not when
it was dynamically allocated.

IIUC, from ssp(3), the checks can be done only if the size of the str is
known at compile time (this is not the case with dynamic allocation) and
if not, and _FORTIFY_SOURCE is defined to 2, it will compute the minimum
size of str (in my case, I guess: 0) so as long as not trying to recopy
the very same string upon itself, a difference of +1 will suffice to 
not fire the __ssp_overlap abort?

Best,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C