Abstract not found

We present the design of an Identity-based CAPability protection system ICAP, which is aimed at a distributed system in a network environment. The semantics of traditional capabilities are modified to incorporate subject identities. This enables the monitoring, mediating, and recording of capability propagations to enforce security policies including the ?-property in the Bell-LaPadula model. It also supports administrative activities such as traceability. We have developed an exception list approach to achieve rapid revocation and the idea of capability propagation trees for complete revocation. A separate access control list is to represent and interpret security policy. Compared with existing capability system designs, ICAP requires much less storage and has the potential of lower cost and better real-time performance. We propose to expand Kain and Landwehr's design taxonomy of capability-based systems to cover a wider range of designs. Introduction Access control is a fundamental ...

Data replication is a technique for increasing the availability of data. Two popular algorithms for maintaining consistency among the replicas are Weighted Voting [1] and Available Copies [2] In recent papers [3] it has been shown that under common circumstances Available Copies (AC) performs better than Weighted Voting (WV). However, the issue of network partitioning due to gateway crashes is ignored in AC. We present an improvement of WV that, if configured accordingly, performs as well as AC, but, unlike AC, also works correctly in the face of network partitioning. 1. INTRODUCTION Data replication in distributed operating systems is a technique for increasing the availability of data. It can also increase the performance of the system, since an application can use nearby copies of the data instead of distant ones. A serious problem, however, is to make the collection of replicated data look like a single object, even under concurrent access. Users should always see the most...

Distributed operating systems have been in the experimental stage for a number of years now, but few have progressed to the point of actually being used in a production environment. It is our belief that the reason lies primarily with the performance of these systems---they tend to be fairly slow compared to traditional single computer systems. The Amoeba system has been designed with high performance in mind. In this paper some performance measurements of Amoeba are presented and comparisons are made with UNIX on the SUN, as well as with some other interesting systems. In particular, short remote procedure calls take 1.4 msec and long data transfers achieve a user-to-user bandwidth of 677 kbytes/sec. Furthermore, the file server is so fast that it is limited by the communication bandwidth to 677 kbytes/sec. The real speed of the file server is too high to measure. To the best of our knowledge, these are the best figures yet reported in the literature for the class of hard...

Remote Procedure Call (RPC) is a widely used communication mechanism in local network based distributed operating systems. It is simple, fast, and straightforward to implement. However, when two or more distant distributed systems are connected, problems arise concerning the protocols, locating services, and other issues. To solve these problems, gateways are introduced. In this paper we discuss various ways in which these gateways can be organized and show how their application in the Amoeba Distributed Operating System has solved the problems cited above. 1. INTRODUCTION As networks of high-performance personal workstations become more widespread, interest in distributed operating systems to make the whole system look like a single time-sharing system is increasing. When the same distributed operating system is running on two widely separated local-area networks, it is natural to think about merging them into a single transparent distributed system. However, because local-a...

The program Amoeba Make, or Amake, is being designed to fulfil the need of a make-like configuration manager capable of exploiting the potentials of the Amoeba distributed operating system. The major design goal is to create a software configuration manager that is both easy to use and efficient. The specification and maintenance of a large configuration should be easy, and should be automated as much as possible. Furthermore, the build process should exploit Amoeba's capabilities and resources when creating or updating a target. In this paper we show how a smart file server can contribute to Amake's efficiency. We also show how a declarative configuration description allows Amake to take full advantage of parallelism and to determine the commands needed for building and maintaining targets. 1. INTRODUCTION The program Amake was designed to fulfil the need of a make-like configuration manager that tries to overcome make's inability to maintain large and complex systems in a convenien...

Distributed systems span a wide spectrum in the design space. In this paper we will look at the various kinds and discuss some of the reliability issues involved. In the first half of the paper we will concentrate on the causes of unreliability, illustrating these with some general solutions and examples. Among the issues treated are interprocess communication, machine crashes, server redundancy, and data integrity. In the second half of the paper, we will examine one distributed operating system, Amoeba, to see how reliability issues have been handled in at least one real system, and how the pieces fit together. 1. INTRODUCTION It is difficult to get two computer scientists to agree on what a distributed system is. Rather than attempt to formulate a watertight definition, which is probably impossible anyway, we will divide these systems into three broad categories: - Closely coupled systems - Loosely coupled systems - Barely coupled systems The key issue that distinguishes these syst...

This paper gives a survey of all common transparent distributed systems. We distinguish between Distributed File Systems (DFS) and Distributed Operating Systems (DOS). Our overview is focussed on systems providing at least access or location transparency. The paper is organized as follows: The introduction offers definitions of the features of each transparent distributed system as well as the services it is able to provide. We also propose a catalog of criteria that enables us to compare different systems independently of implementation done. The main entries we make are heterogeneity of the system's environment, communication strategy, as well as naming and security issues. Finally, we examine the reliability and availability of the separate systems and the way these issues are achieved. The following section consists of the survey. The description of each system is organized as follows: First, we introduce the main goal the system was developed for, the classification of th...

INTRODUCTION Roughly speaking, we can divide the history of modern computing into the following eras: 1970s: Timesharing (1 computer with many users) 1980s: Personal computing (1 computer per user) 1990s: Parallel computing (many computers per user) Until about 1980, computers were huge, expensive, and located in computer centers. Most organizations had a single large machine. In the 1980s, prices came down to the point where each user could have his or her own personal computer or workstation. These machines were often networked together, so that users could do remote logins on other people's computers or share files in various (often ad hoc) ways. Nowadays some systems have many processors per user, either in the form of a parallel computer or a large collection of CPUs shared by a small user community. Such systems are usually called parallel or distributed computer systems. This development raises t

In this paper we will give an up-to-date overview of the Amoeba distributed operating system microkernel. We will examine process management, memory management, and the communication primitives, emphasizing the latter since these contains the most new ideas.