A more abstract view of the generalized
Part of the generalized
open() problem is that
open()s silently cross what I will call 'security
contexts'. Here a security context is both what you can do and where
the data is coming from; read versus write versus run a pipe, local
files versus remote URLs, and so on.
When something is security sensitive (and
open() is here), it should
either be explicit about what security context it is operating in,
or it should at least be explicit about the fact that it is crossing
them. In other words, this is one of the places where you deliberately
want to break abstractions, so that there is no possibility of code
accidentally operating in the wrong security context.
(I suspect that these things sneak into languages partly because the language designers did not see them as crossing security boundaries, and in part I think this may be because security boundaries sometimes only become obvious with painful experience. After all, no one deliberately puts security holes in their language or their library.)
Comments on this page:Written on 12 December 2007.