[PLUG] Trying to learn low level Linux programming for cs201...

[Tim]

Hi Fred,

> Could you elaborate, please, or point to such?
> Regards
> Fred James
> 
> PS:  Sorry - I should narrow the scope a bit - I meant the "unsafe" part 
> - thank you.

Sure.  I guess a good file-related example would be fscanf().  If you
try to read in strings or other variable length arguments without
putting an explicit length limiter in there, you're essentially
guaranteeing yourself a buffer overflow.

Another example might be fprintf() which, while typically safer, is
dangerous to include user-supplied values in the format string itself.
For instance, doing something like:
  fprintf(FILE_pointer, user_supplied_string);

Can allow for arbitrary code execution amongst other things.  Of course
this issue isn't limited to fprintf()...  All of the printf() family
exhibit this.

Finally, consider popen() which returns a FILE object pointing to a
stream.  It executes '/bin/sh -c ...' with your input string.  If any
user-supplied values slip into that string, you're in big trouble.  Even
if this wasn't an issue, popen() and it's friend system() have a
horrible interface in that they don't return good information about
whether or not your external process failed.  If you want to pipe data
to your sub process, forget trying to get anything back on it's stdout.

Other examples of poor wrapper function design (temporary file creation,
many bad string functions) move further away from FILE-specific stuff,
but one often finds that using just some of these higher-level
interfaces is hard.  You often have to either just write it yourself at
the low level or give in and use all of libc's bad wrappers.

In the end, these interfaces can be used safely of course, if you know
what you're doing.  A better interface can of course be used unsafely if
you try hard enough.  To distinguish between the two, you should ask the
question: 
  "Is the most obvious way to do a thing also the safe way of doing it?"

Comments welcome,
tim