42. Operating Systems, Networks and Cookies

Part of CS:2820 Object Oriented Software Development Notes, Spring 2021
by Douglas W. Jones
THE UNIVERSITY OF IOWA Department of Computer Science


Objects in Operating Systems

Consider what happens when you open a file in Java. You write something like this:

File f = new File( "filename" );

From a java perspective, the result is that f is the handle on (or pointer to) an object of class File, where methods operating on that class do things like reading or writing the file.

It is not that simple! Files are operating system objects. That means that you can open the same file (in this case, a file named filename) whether you are writing your program in machine language, FORTRAN, C, COBOL, C++, Java, Python or Perl. Some of these languages aren't at all object oriented, and some of them are not type safe. C++, for example, is object oriented but it is not type-safe. A C++ programmer can create an object and then trick the programming environment into treating it as an object of a completely different class.

Non-type-safe languages are required for some applications. For example, to implement the storage manager and garbage collector that underly Java, you need a language that allows you to do arbitrary arithmetic on pointers. You can do this in C or C++, but not Java or Python.

Operating systems on modern computers that have memory-management units (also called MMUs) offer each user process a distinct separate memory address space. In such a system, the memory used by the operating system to store system objects such as files and timers is totally inaccessible from user programs. When you open a file, the operating system allocates a file object in the system memory, and then it hands the user program a handle for this object.

For most objects, the object handle is just the memory address of the object in the program's memory address space. When a user program accesses a system object, this model does not work because the user program cannot access the system memory space.

If you are writing a Java program, the Java run-time system allocates a Java object of class File in your user memory space, but this object is not the system file object. Instead, it is an interface or wrapper around the system object. One field of this object is the handle for the system object, and the methods of Java's class File serve primarily to translate Java's file access methods into those of the underlying operating system.

So what is an operating-system-level file handle? Here is a bad idea:

BAD IDEA: A system file handle is the memory address of the file object inside the operating system's private memory.

The problem with this idea is that the file handle is in the user's address space where the user can fiddle with it. If you are writing your code in assembly language, FORTRAN, C or C++, none of which are type safe, your program could freely ask the system to perform a file operation using any arbitrary data as a file handle. This would causing the operating system to access random areas of its own memory and try to use those areas as system file objects. Protecting against abuse of this is very difficult. What if, by chance, a malicious user manages to invent the memory address of a real file object in the operating system's address space where that file does not belong to that user?

How Unix/Linux does it: A system file handle is an integer index into a small table in the operating system's memory address space. This table contains the memory addresses of the files that the current user is entitled to access.

This scheme allows the user to mess up, but the worst that the user can do is access a file that that user already is permitted to use.

This is a very old scheme, dating back to the early days of FORTRAN. Fortran input/output was done relative to unit numbers. Originally, the unit numbers were the numbers of physical tape drives, and the operation of "opening a file" was done by outputting a message telling the computer operator to mount the requested tape on the indicated drive. Later, in the 1960s, as operating systems matured, unit numbers became indexes into an operating-system table of the files that the current application had opened.


While most of us think of cookies as a phenomonon of the World-Wide Web, where web sites leave cookies on your machine, forcing you to carry information about yourself on behalf of the web site (such as tracking information or personal browsing histories), the term appears to have originated in the documentaiton for the standard library of the C programming language. Specifically, the library includes services called called ftell() and fseek() that can be used inquire about the current position of an input/output stream and to set the position in that stream.

In the original Unix implementation of the C stream file model, positions in the stream were simply the integer number of bytes from the start of the stream, but when C was ported other operating systems, the developers quickly learned that some file systems made it difficult to count bytes from the start of a file. Here is how they documented file positions in the Unix Programmer's Manual, Vol I, part 3, published by Bell Laboratories in 1979, revised 1983:

Ftell returns the current value of the offset relative to the beginning of the file associated with the named stream. It is measured in bytes on UNIX; on some other systems, it is a magic cookie, and the only foolproof way to obtain an offset for fseek.

The general definition of a magic cookie you can infer from this brief mention is that it is a value returned to the user by some system where the system understands the construction and use of that value but the user is not expected to be able to interpret or manipulate it. The only useful thing the user can do with a cookie is give it back to the system so that the system can interpret it.

So, how do we use cookies to represent objects in a world where we still have something akin to classes, but all fields and methods are static? We use cookies as object handles, and we have each class maintain a collection of all objects of that class. Here is an example where class C offers access to objects of class Cdata using integer handles:

static class C {
    static private int alloc = -1;   // used to allocate instances
    static private Cdata f[maxSize]; // all of the instances
    static public int C() { // the constructor
        alloc = alloc + 1;
        f[alloc] = new Cdata();
        return alloc;   // return a handle for the new instance
    public Cdata get( int handle ) { // an example getter method
        return f[handle];
    public void set( int handle, Cdata value ) { // an example setter
        f[handle] = value;

Obviously, this is a bit stupid because class Cdata is fully exposed to the users, but we could easily add more methods to C, where each method performed a different operation on the underlying Cdata objects and where users never ever actually see the underlying objects.

The above implementation assumes that the constant maxSize gives the maximum number of members of class C that will ever be needed. More sophisticated implementations will allow users to deallocate objects as well as allocate them, and will include (in the allocator) a search for a free object so that storage can be reused.

Integer handles such as the above are dangerous. A user could incrment their handle and the result would be the handle for a different object, perhaps one that that user should not be able to use. What we want is a way to give the user a handle that, despite the fact that the user can mess with it, messing will very likely be detected. Here's an example that works:

static class C {
    static private int alloc = -1;   // used to allocate instances
    static private Cdata f[maxSize]; // all of the instances
    static private int keys[maxSize];// the keys to the instances
    static public int C() { // the initializer
	assert (maxSize * keyRange) <= Integer.MAX_VALUE;
        alloc = alloc + 1;
        f[alloc] = ??
        key[alloc] = random.nextInt() % keyRange;
        return alloc + key[alloc] * maxSize;  // return a secure cookie
    public Cdata get( int cookie ) { // an example getter method
        int i = cookie % maxSize;    // the item number
        int k = cookie / maxSize;    // the key
        if (k != key[i]) throw new IllegalHandleException();
        return f[i];
    public void set( int cookie, Cdata value ) { // an example setter
        int i = cookie % maxSize;    // the item number
        int k = cookie / maxSize;    // the key
        if (k != key[i]) throw new IllegalHandleException();
        f[i] = value;

Here the cookie (object handle) given to the user has two parts, the item number and a randomly assigned key. Messing with the cookie will be very likely to be detedted because the user would have to guess the key fields of items the user has never seen. This can be made arbitrarily secure by using a larger key range, so long as keyRange*maxSize fits within an integer; greater security requires switching to longer integers.

The above implementation assumes a pseudo-random number stream random and it assumes that the constant maxSize gives the maximum number of members of class C that this mechanism can allocate, while keyRange gives the size of the key. More sophisticated implementations will allow users to deallocate objects as well as allocate them, and will include (in the allocator) a search for a free object so that storage can be reused.

In the late 1960s and early 1970s, when object-oriented programming was just being invented, people like David Parnas developed methods of modularizing programs, creating software architectures that were almost object-oriented while writing code in languages like Fortran IV. Fortran IV does not support classes, but it is straightforward to write compilation units (separately compiled pieces of a large program) where each unit contains one callable subroutine per method of a logical class and a common block (a block of static variables shared between the subroutines) holding the representations of all instances of that class.

This method remains in use today in distributed systems where code is divided between clients and servers. In such a system, it is natural to have one server to implement each class, where the server holds all values of that class in its internal memory and offers clients the ability to perform actions on members of the class.

This solution was formalized by Andrew Tannenbaum in his development of the Amoeba operating system. He referred to the keys discussed above as salt applied to the integer handle of each object.

In Amoeba, clients (user programs) communicate with servers over a network. Users or the system can write servers, but all communication from clients to servers is by network packets. To call a method of an object, you send a message to that object's server -- a server that implements all methods on all objects of that class. The message must include a cookie that identifies the object to be manipulated, and the result of that manipulation is a reply message.

The Amoeba system was designed (with funding from the European Space Agency) to create supercomputers from clusters of inexpesive small computers. Amoeba uses this framework extensively, and since it implements the basic "salted cookie" mechanism in standard "boilerplate" code that is distributed with the system, users can think in entirely object-oriented terms when developing applications on Amoeba, without ever worrying about building their own "salted cookies".

Amoeba is more complex than indicated here because it adds, to each object handle, a set of access rights. The salting scheme is further modified to prevent users with a limited-access handle from increasing their access rights, for example, given a read-only file handle, while a user can change the read-only access rights bit to read-write, the code in each method that checks the salt on the cookie will detect this because the salt-checking code includes the access rights in its check.

With Tannenbaum's scheme, the only way a user can successfully compute the right salt value for their cookie is to know the secret key from the server's table and the access rights they want. So long as the server keeps this secret, only the server can construct cookies holding the right salt values. So, servers that use access rights have to offer a method to users that allows the users to create a new cookie that references the same object but with fewer access rights. When a user creates a new object, the user gets all rights to that object in its cookie. The user can ask the server to create new cookies with fewer rights and then pass those restricted cookies to others. The others can further restrict them, but there are no tools allowing a user to gain rights on a cookie that has already been restricted.