These pages log some of my linux hacking ventures in the hope that they might help some frantic programmer caught in a deadlock. Some of the details are Debian specific, however, they are applicable to other flavors with some minor changes.



Moving on from 2.4 to 2.6

September 13, 2004

Recently, I migrated to kernel 2.6.8 on my Debian Sarge machine (Pentium-4) from kernel 2.4.25 (yeah! I waited quite a while... lack of inspiration, I guess). Everything went picture-perfect as far as configuration and compilation is concerned (here's the .config). However, booting into the new kernel resulted in some glitches. I've listed a few that I encountered along with their solutions.



strncpy: the untamed beast

August 25, 2004

I have my share of programming blues in C, but I really must be a sucker for the pitfalls of strncpy. Although I have known and used this fella several times, there are almost as many times that I have stared at a Segmentation Fault due to buffer overflow resulting from it's incorrect use. To remain focused on the topic this article will not go into details of the possible havoc that can result from a buffer overflow. Googling for it shall bring up several relevant sites.

You see, according to the man page "... strncpy() function copies up to n characters, including the terminating null character, from the string pointed to by s2 into the buffer pointed to by s1. Once strncpy() has copied n characters to s1, it does not append a terminating null character." Also, it goes without saying that the programmer is entirely responsible for allocating any storage. 


	char *strncpy(char *dst, const char *src, size_t n);
When a call to strncpy is made, the function copies (or attempts to copy) 'n' characters from 'src' to 'dst' without performing any checks whatsoever for the presence of a null terminator. So, if our 'src' is smaller than the size of the 'dst', strncpy will pad null characters to the rest of 'dst', however, if the 'src' is larger in size than the 'dst', the copying is truncated and what you have in 'dst' is an unterminated string.
Another point that most people miss is that the length 'n' is in no way related to the size of 'dst'. What this really means is that the programmer has to, either pick 'n' cleverly, or perform tedious checks to avoid going over the size of 'dst'.

OpenBSD, on the other hand, offers a more cautious variant of strncpy in the form of strlcpy. 

	size_t strlcpy(char *dst, const char *src, size_t sz);
According to the man page of strlcpy and strlcat "Unlike those (strncpy and strncat) functions, strlcpy() and strlcat() take the full size of the buffer (not just the length) and guarantee to NUL-terminate the result (as long as size is larger than 0 ..."
The biggest appeal of strlcpy, for safety conscious programmers, lies in it's two-fold benefits. First, the size of copy ('sz') is related to the destination being of the size of 'dst' and second, it copies over 'sz'-1 characters to 'dst' and then appends a null terminator.

Here's my little hack to get a strlcpy-esque function working under linux.



Playing with libnet and pcap

coming soon...


Please send any comments or suggestions to h00liganism_8_yahoo_o_com ;-)  [_8_ = at the rate, _o_ = dot, ;-) = wink]

© Rahul Jadhav, 2004.
Last updated Wednesday September 15, 2004