Implicit generalized open()'s are dangerous

December 12, 2007

A number of languages have open() functions that are generalized by default; they open more than plain files, sometimes far more. Such functions are dangerous bear traps lying in wait for the unwary and insufficiently paranoid, because what the programmer thinks is a simple file open may be something very different and more dangerous. In turn, this means that all an attacker needs to do is find some way to supply a 'file name' that your program will try to open.

There's two core problems: the generality is implicit, not explicit, and it is in what you use for a common case that neither needs nor wants the generality. This means that the full potential of what the code can do is not immediately obvious when you read (or write) 'open(filename)', and that you will be writing it a lot. Adding to the problem is that this is a hard mistake to notice. Your code works; it just has extra 'features' that you don't actually want.

(Even if there is a way to be explicit, people are lazy and sooner or later someone is going to use the implicit way when they shouldn't have.)

As you may have gathered, I don't particularly like such open()s; I feel that they are a prime example of an error-prone interface.

Written on 12 December 2007.
« A surprise about Linux serial consoles
A more abstract view of the generalized open() issue »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Dec 12 00:07:09 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.