Program errors are a source of information leaks. Tracking these leaks is hard because error propagation breaks out of program structure. Programming languages often feature exception constructs to provide some structure to error handling: for example, the try...catch blocks in Java and Caml. Mainstream information-flow security compilers such as Jif and FlowCaml enforce rigid rules for exceptions in order to prevent leaks via public side effects of computation whose reachability depends on exceptions. This paper presents a general and permissive alternative to the rigid solution: the programmer is offered a choice for each type of error/exception whether to handle it or not. The security mechanism ensures that, in the former case, it is never handled and, in the latter case, it is always handled with the mainstream restrictions. This mechanism extends naturally to a language with procedures and output, where we show the soundness of the mechanism with respect to termination-insensitive noninterference.

XE is a programming language designed and implemented at the Helsinki University of Technology by the ExBed project. The design of XE is based on the CLU programming language. This paper discusses differences between the two languages and the design decisions of XE. 1. Background The XE language [Arkk89] and its programming environment have been developed within the ExBed project, which was established to develop software tools for construction of embedded expert systems. The project needed a general purpose programming language with added facilities for rule-based programming. High level abstraction mechanisms and the possibility for efficient static semantic analysis were considered crucial for the language. The main reason for this was the wish to perform as much verification and optimization as possible at compile time to satisfy the stringent requirements of embedded systems. There existed no programming language that satisfied our needs and therefore we decided to design a new pr...

Java offers the real possibility that most programs can be written in a type-safe language. However, for Java to be broadly useful, it needs additional expressive power. This paper extends Java in one area where more power is needed: support for parametric polymorphism, which allows the definition and implementation of generic abstractions. We discuss both the rationale for our design decisions and the impact of the extension on other parts of Java, including arrays and the class library. We also describe optional extensions to the Java virtual machine to allow parameterized bytecodes, and how to verify them efficiently. We have extended the Java bytecode interpreter to provide good performance for parameterized code in both execution speed and code size, without slowing down non-parameterized code. 1 Introduction Java [Sun95a] is a type-safe, object-oriented programming language that is interesting because of its potential for WWW applications. Because of the widespread interest in ...

Much work has been done in the last decade in the related areas of object-oriented programming languages and object-oriented databases. Researchers from both areas now seem to be working toward a common end, that of an object management system, or OMS. An OMS is constructed similarly to an OODB but provides a general purpose concurrent object-oriented programming language as well, complementing the OODB query facilities. In this paper, we will define several different types of object systems (object servers, persistent OOPL's, OODB's and OMS's) in terms of their interfaces and capabilities from the viewpoint of how these support the requirements of cooperative information systems. We will examine the distinguishing features and general architecture of systems of each type in the light of a general model of OMS architecture. Copyright 1992 Steven S. Popovich and Gail E. Kaiser Keywords: concurrency control, locking, storage management, transactions, type management 1 1. Introductio...

What? .......................................................................... 211 C++ Is to C as Lung Cancer Is to Lung .....................................214 The Evolution of a Programmer ................................................215 Part 3: Sysadmin's Nightmare ...................219 11 System Administration ............................................221 Keeping Unix Running and Tuned ............................................223 Disk Partitions and Backups......................................................227 Configuration Files....................................................................235 Maintaining Mail Services ........................................................239 Where Did I Go Wrong? ...........................................................241 12 Security ..................................................................................243 The Oxymoronic World of Unix Security .................................243 Holes in the Armor ....................................................................244 The Worms Crawl In .................................................................257 13 The File System..............................................................261 What's a File System? ...............................................................262 UFS: The Root of All Evil.........................................................265 xiii 14 NFS ............................................................................................283 Not Fully Serviceable ................................................................284 No File Security.........................................................................287 Not File System Specific? (Not Quite)...................................... 292 Part 4: Et C...