Summarizing a bit, here, for bandwidth's sake: Seems we have a problem with the file locking mechanism of the hsqldb product that may manifest (from Kevin's report) mainly in Windows (NOTE: after testing, it is actually simply EASIER in Windows, vs. Linux/*nix). I believe Thomas' primary platform WAS Windows, followed by various *nix, then Linux (remember, the project started in 1995, prior to the Blackdown port and acceptance), so I think Campbell is correct, and we need to revisit our implementations of the File class more carefully, epecially, if, as he's found, this results in a possible Security issue.
Googling for some guidance: http://www.google.com/search?hl=en&q=%22cooperative+file+locking%22+java returns 52 hits, starting with Sun's Java2 1.3.1 and 1.4.0 javadocs at: 1.3.1: http://java.sun.com/j2se/1.3/docs/api/java/io/File.html 1.4.0: http://java.sun.com/j2se/1.4/docs/api/java/io/File.html both of which cite the call to the "createNewFile()" Method of the File class while observing that "(this) method, in combination with the deleteOnExit() method, can therefore serve as the basis for a simple but reliable cooperative file-locking protocol." and an Almanac entry suggesting that this has been in force since the 1.2 version of the JRE. Also, in both versions (and, intuitively since the 1.2 version) reference is made to the throwing of a SecurityException, if a security manager exists and "...its SecurityManager.checkWrite(java.lang.String) method denies write access to the file." Hmmm....SecurityManager is not yet a class or Interface we implement in hsqldb. >From Linden: http://java.sun.com/people/linden/faq_d.html comes the obsevation (search for "cooperative") that "...a global server issuing a token (and periodic "are you still using it" messages) is a pretty good way to do cooperative file locking too." and "...There are classes (dedmike--File? Hmmmm...) in Java which may supply 'probably' unique ids, with varying levels of reliability --- but a dual processor machine with two JVMs running could easily generate duplicate ids.(!)" so the environment CAN make a difference, apparently, as can the choice of JVM and physical/infrastructural implementation. (NOTE: Can this situation also be solved by a 'SecurityManager' class, even across SMP architectures, or with multiple JVMs instantiated (as in many J2EE server roll-outs?)?) Some requirements guidance, and an explicit hint as to a possible solution comes from, of all places, PerlCGI (http://tef.selcuk.edu.tr/~adem/docs/cgires/cgi-tips.htm#lock ), so, we're not alone, in the Java ORDBMS universe, in having this problem. >From brief reading, it seems that Campbell is right, in that this is one of those 'seldom-if-ever-touched' issues that has come up and seems to be a possible or probable serious Security flaw in our product. Environment, physical and JVM/OS plays a role, and, I believe we could probably work to duplicate this on *nix/Linux platforms, even without using a 'pure Java' solution. So, bottom line, we need a SecurityManager class, to complement the v.1.3+ JVM 'File' class and take advantage of the Public interface. Problem is, it can implemented only for SEv.1.3+ of the JVM. However, we can make it available as an option to the product, choosable either by the ant build process, the CodeSwitcher, or the IzPack installer. The class should be an 'intuitive' one, dynamically sensitive to the OS, the environment (SMP? How many? Explicitly-created and available JVMs? How many?) and the system infrastructure and implementation of hsqldb. This will be a heavy-weight addition to the hsqldb product, taking up additional cycles and memory. Since its a Security issue, its important. The question is, important enough to delay the 1.7 RC and Final? Campbell? Thanks, Kevin, for the heads up...credit where credit is due. In my test, I could duplicate a full JVM crash that, in more skillful hands, could result in a more serious sytems security failure. This is going in the 'TODO' Tasker, with Campbell and myself cited as 'Assigned.' --Michael J. Cannon/dedmike The previous messages in this thread have been deleted in this reply for bandwidth preservation. _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
