In a message dated Sat, 26 Oct 2002, Trey Harris writes:
> One of the cardinal rules of defensive programming, at least in the Unix
> world, is that you shouldn't check if you can do something--you should
> just try to do it. If it fails, *then* you check to see why. Many, many
> potential security problems can be avoided that way.
Oh, another thought--this practice not only saves you from security
problems, but it also makes your code more general. You may be running
under systems like AFS (Andrew File System), where the code:
$canwrite = -w $filename;
open FILE, ">$filename";
$didwrite = print FILE "hi, mom!\n";
close FILE;
if ($canwrite != $didwrite) {
print "Uh....\n";
}
Can actually cause the seemingly inexplicable behavior of printing
"Uh...", even in the absence of race-condition behavior, because in AFS
you may be able to write to a file because of your Kerberized ACL, even
though the Unix permissions may suggest the file is not writable, which is
all -w takes into account (unless you use the access pragma).
The point is, sysadmins and other software may be doing the best they can
to fool your program into thinking the world is different from what it
actually is. Your program should just "go along for the ride," not
attempt to look around and see if the world really *is* how it "should be"
under some narrow view of the world corresponding to the system on which
your program was developed.
Speaking from a decade of sysadmin work, very little is more annoying than
making it possible for someone else's program to do its job, only to have
the program refuse to do it anyway because it "thinks" it shouldn't be
able to. "Why doesn't the program just *try* it??" is the sysadmin's
plaint, and rightly so.
Trey
