Browse Prior Art Database

Resource constraints in Java by means of a classfile modification

IP.com Disclosure Number: IPCOM000010128D
Original Publication Date: 2002-Oct-24
Included in the Prior Art Database: 2002-Oct-24
Document File: 3 page(s) / 46K

Publishing Venue

IBM

Abstract

The standard J2SE (Java2 standard edition) classes are currently designed assuming the existence of a security manager which is periodically asked to check that the running code is authorised to perform the desired operation. A typical operation would be the creation of a FileOutputStream object allowing data to be written to a file. Once this permission is granted by the security manager the assumption is that the code will be well behaved and impose some limitations on the number of bytes written. Either malicious or buggy code could however exceed the capacity of the file system and cause the entire machine to crash in the worst case. Hence it is desirable that we impose some limitations on the quantity of data written and allow that those limits be varied dynamically during the program lifetime.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 1 of 3

Resource constraints in Java by means of a classfile modification

The standard J2SE (Java2 standard edition) classes are currently designed assuming the existence of a security manager which is periodically asked to check that the running code is authorised to perform the desired operation. A typical operation would be the creation of a FileOutputStream object allowing data to be written to a file. Once this permission is granted by the security manager the assumption is that the code will be well behaved and impose some limitations on the number of bytes written. Either malicious or buggy code could however exceed the capacity of the file system and cause the entire machine to crash in the worst case. Hence it is desirable that we impose some limitations on the quantity of data written and allow that those limits be varied dynamically during the program lifetime. We would like to support the case of a user opening more than one file and being given some total limit on the resources used; any bytes written to one file will reduce the amount that can be written to the others. In a similar way we would like to impose constraints on the rate at which data is written to or read from files or send down communication links.

    In an ideal world we would ensure that this checking should be efficient, flexible and require no modifications to the standard J2SE classes as shipped by multiple vendors today. We imagine a separate set of class files which would be installed in the classpath and which would cause the resource limitations to be rendered effective for a given Java* VM.

    The chosen method for imposing resource constraints is to define a set of subclasses eg grid.io.FileOutputStream which is a subclass of java.io.FileOutputStream. Each subclass then overrides the 'resource consuming' methods (typically native) and imposes the desired constraints before delegating the actual work to the superclass method. The trick is to get the untrusted code to employ these subclasses rather than the original classes. Hence the programmer will code

FileOutputStream stream = new FileOutputStream("big1.out");

intending to create an object of class java.io.FileOutputStream. but the JVM will actually create an object of class grid.io.FileOutputStream. Typically this will be a subclass of one of the java classes but may alternatively choose to expose the same set of interfaces and then delegate all calls to an internal object of class eg java.io.FileOutputStream. The key to this design is the definition of a process for modifying the class file which defines code to be run. In a typical implementation we will arrange that this class file is loaded through some specific classloader which we will provide for the purpose of loading 'untrusted' code. We will intervene between the process of finding the class file bytes (findClass) and the process of defining the class (defineClass); the normal point for classfile modifications. In principle the process of clas...