A more abstract view of the generalized open() issue

December 12, 2007

Part of the generalized open() problem is that such generalized 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.

As a corollary, namespaces that cross security contexts are a danger sign. Firefox has had problems with because its internal files and resources are partly named using URIs in the chrome:// scheme, so lots of things that accept URLs have to be blocked from using them (and sometimes stuff using chrome:// URLs had to be blocked from using other sorts of URLs). And of course there's the great fun to be had because browsers accept 'javascript:' as a scheme in URLs.

(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:

From at 2007-12-13 05:39:55:

You are quite right and the generic open()-problems are always worth mentioning.

My language is C, so this example can be somewhat narrow for general discussion. But, if we limit ourselves to C, wouldn't the safe route be exactly opposite: instead of stat()'ing and open()'ing based on the results of the former, shouldn't we open() and then fstat()? The thing in the latter would naturally be the use of a file descriptor, hence the file we stat()'ed would be exactly the same one we open()'ed.

I am also little unsure what dangers a generic open() would pose in this langugage; the system call open() should not make any use of the file whatsoever, right?


PS. As a first time poster to this blog, I had overly hard time figuring out why and where I should login, what on earth the signing of a message means, and so forth.

From at 2007-12-13 05:57:29:

Oh, nice.

I, like most of us I presume, thought that the word "log" refers to some internal logs located in the server environment; certainly not something to be pasted to the HTML.

I also thought that I was reading a blog, not some closed-shop Wiki. I have nothing against (D)Wiki nor authentication, but maybe this scheme would require a second thought.[1] Given that many consider even CAPTCHAs to be extravagant for blogs.

Cheers, Mr.

[1] "Because DWiki is hard-coded to require authentication before people can write comments [...]".

By cks at 2007-12-13 11:56:19:

I don't think that C's open() has these issues as such; I'm mostly thinking about languages like Perl and PHP. The stat/open race is another issue (and a general problem, not specific to C); off the top of my head, it's a problem of unexpectedly mutable name to object bindings.

My apologies about the unclear help text on the add comments page; I'll try to revise it to be clearer. (They are a relic of when I had a very different idea of what DWiki would be used for, much more a wiki-thing for documentation and far less a blog-oid engine.)

PS: the comment in the operations documentation about requiring authentication for comments is misleading when read out of the (unclear) technical context. Everyone browsing WanderingThoughts is 'authenticated' as far as DWiki is concerned; it's just that most people are authenticated as the guest user.

Written on 12 December 2007.
« Implicit generalized open()'s are dangerous
Doing one-shot booting with GRUB »

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

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