Hi Dave -
The fileID is an opaque value that just happens to correspond to some data structure that we are not supposed to know about, but it is easier to handle the issue in the Win32OSProcessPlugin that to try to design a platform independent solution that can be incorporated into FilePlugin for all supported platforms.
*Gasp* If I've ever seen "evil" code, this got to be it ;-) Not because it's badly written but because it's designed to break the (supposed) encapsulation of the file structure. If the file plugin code ever changes (such as when removing the fileSize) that code will make the VM explode.
The main lesson for me here is that if it's *that* easy to fake a file handle we've got a real problem with security. Basically, all of our I/O operations are prone to this kind of attack and I don't even want to think about all of the different ways in which this could be exploited.
In order to fix this, I just added a tiny little hash table to the windows file plugin which checks whether a file handle is genuine, e.g., has been produced inside the the file plugin or not. Since that hash table is not publicly accessible you can't store into it, thus you can no longer fabricate a random file handle.
BTW, this is not designed "just so your evil code breaks" - as far as I am concerned it's actually a *major* step forward towards a secure VM design because one of the effects this achieves is that the handle (token) that's used in the plugin is actually a capability to invoke a given set of primitives and no others, and it is solely at the plugins discretion which set of primitives to assign to which handle. Nice, simple, and secure (just as it should be).
One of the effects of that change is that it immediately makes the session ID superfluous from a security POV. The worst that could ever happen is that an "old" handle refers to a "new" file (if handles aren't unique across sessions) but an invalid handle can never be used in any of these operations. (note that from a security POV an old handle referring to a new file is indistinguishable from cloning an existing handle which is something that we don't deal with either right now - fixing this would be straightforward if we were able to deal with oops instead of third-party handles but that would require dealing with oop relocation during GC; ouch).
And now that we got this done ;-) we can start talking about how to expose the functionality that you need in a nice and cross-platform way. Like, accessing standard file handles: What's wrong with a primitiveGetStdFileHandle that takes an integer argument for the kind of standard handle to retrieve (0 - stdin, 1 - stdout, 2 - stderr)? Sounds simple enough to me. Any others you'd need?
Cheers, - Andreas