I thought that everyone had read, by now, Robert Fulghums classic book, “All I Really Need to Know I Learned in Kindergarten”—newly released in an expanded 15th anniversary edition, which Amazon.com unaccountably failed to mention when I searched that site for “kindergarten” combined with the authors name. Many thanks to the readers of the e-mail version of this column who promptly told me of the oversight.
Fifteen years is a long time, though, and perhaps that explains why NASAs Spirit rover had storage management problems soon after landing on Mars—and possibly also accounts for that half-gigabyte of hard-drive space that I recently recovered on my laptop machine.
The common connection that I suspect is expressed in the simple “Kindergarten” rule, “If you make a mess, clean it up.” The Spirit rover got into trouble because its flash memory storage became cluttered with files—in all likelihood, a mixture of log entries and meant-to-be-temporary scratch pads—that shrank the free storage space to the point that the machine went into a cycle of reboots.
My laptop, I discovered when looking at a report of its most fragmented files, had more than 500 megabytes of image files accumulated in a temporary directory—where they had been stranded when Microsoft Word had choked, on various occasions, when I tried to incorporate those images into reports. My workaround was always to go back and compress the image more aggressively before inserting it into a document, but it turned out that the remnants of my unsuccessful initial attempts had remained.
Im not only concerned about the waste of storage space—both mine and Spirits—thats often recoverable only with time-consuming scrutiny by at least an intermediate user. Im also concerned that these temporary files, which developers dont even bother to delete, may show carelessness—or cluelessness—in other ways as well.
For example, if an application routinely appends data to a file with a predictable name, located in whats usually a freely-writable directory such as /tmp, then the conditions are created for a symlink attack. That is to say, an attacker replaces the target file with a symbolic link to another file that requires higher privileges to modify; when someone with those privileges runs an application that thinks its using the target file, theyre actually writing data on top of something else—like a critical system file, thus disabling the system.
This and related vulnerabilities have been known to arise in many places, at least one within the last month alone, and probably exists in many more.
Meanwhile, if you make a mess, clean it up: its a good rule. Any piece of code whose normal behavior can generate a temporary file should include some mechanism for removing it, or at least for reporting the space-consuming action and letting the user decide what to do. And no file should ever be created without consideration of the privileges that it makes available, not only by intention to its creator, but also to others as well.
Tell me about your development problems, temporary or otherwise, at peter_coffee@ziffdavis.com.
