DOCSLIB.ORG

Tahoe-LAFS Documentation Release 1.X

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Tahoe-LAFS Documentation Release 1.X Tahoe-LAFS Documentation Release 1.x The Tahoe-LAFS Developers Sep 22, 2021 Contents 1 Welcome to Tahoe-LAFS! 3 1.1 What is Tahoe-LAFS?..........................................3 1.2 What is “provider-independent security”?................................3 1.3 Access Control..............................................4 1.4 Get Started................................................4 1.5 License..................................................5 2 Installing Tahoe-LAFS 7 2.1 Microsoft Windows...........................................7 2.2 Linux, BSD, or MacOS.........................................8 3 Building Tahoe-LAFS on Windows9 4 Building Tahoe-LAFS on Linux 11 4.1 Prerequisites............................................... 11 4.2 Install the Latest Tahoe-LAFS Release................................. 12 5 Building Tahoe-LAFS On A Desert Island 13 5.1 How This Works............................................. 14 6 How To Run Tahoe-LAFS 17 6.1 Introduction............................................... 17 6.2 Do Stuff With It............................................. 19 6.3 Socialize................................................. 20 6.4 Complain................................................. 20 7 Magic Wormhole Invites 21 7.1 Magic Wormhole............................................. 21 7.2 Invites and Joins............................................. 21 7.3 Tahoe-LAFS Secret Exchange...................................... 21 8 Configuring a Tahoe-LAFS node 23 8.1 Node Types................................................ 24 8.2 Overall Node Configuration....................................... 24 8.3 Connection Management......................................... 28 8.4 Client Configuration........................................... 31 8.5 Frontend Configuration......................................... 32 i 8.6 Storage Server Configuration...................................... 33 8.7 Storage Server Plugin Configuration................................... 34 8.8 Running A Helper............................................ 34 8.9 Running An Introducer.......................................... 34 8.10 Other Files in BASEDIR......................................... 35 8.11 Introducer Definitions.......................................... 36 8.12 Static Server Definitions......................................... 36 8.13 Other files................................................ 38 8.14 Example................................................. 38 8.15 Old Configuration Files......................................... 39 9 Tahoe-LAFS Architecture 41 9.1 Overview................................................. 41 9.2 The Key-Value Store........................................... 42 9.3 File Encoding............................................... 42 9.4 Capabilities................................................ 43 9.5 Server Selection............................................. 43 9.6 Swarming Download, Trickling Upload................................. 45 9.7 The File Store Layer........................................... 45 9.8 Leases, Refreshing, Garbage Collection................................. 45 9.9 File Repairer............................................... 46 9.10 Security.................................................. 47 9.11 Reliability................................................ 47 10 The Tahoe-LAFS CLI commands 49 10.1 Overview................................................. 49 10.2 CLI Command Overview........................................ 49 10.3 Node Management............................................ 50 10.4 File Store Manipulation......................................... 51 10.5 Storage Grid Maintenance........................................ 57 10.6 Debugging................................................ 57 11 The Tahoe REST-ful Web API 59 11.1 Enabling the web-API port........................................ 60 11.2 Basic Concepts: GET, PUT, DELETE, POST.............................. 60 11.3 URLs................................................... 61 11.4 Slow Operations, Progress, and Cancelling............................... 63 11.5 Programmatic Operations........................................ 64 11.6 Browser Operations: Human-oriented interfaces............................ 73 11.7 Other Useful Pages............................................ 85 11.8 Static Files in /public_html........................................ 88 11.9 Safety and Security Issues – Names vs. URIs.............................. 88 11.10 Concurrency Issues............................................ 89 11.11 Access Blacklist............................................. 89 11.12 URLs and HTTP and UTF-8....................................... 90 12 Tahoe-LAFS SFTP Frontend 93 12.1 SFTP Background............................................ 93 12.2 Tahoe-LAFS Support........................................... 94 12.3 Creating an Account File......................................... 94 12.4 Configuring SFTP Access........................................ 94 12.5 Dependencies............................................... 95 12.6 Immutable and Mutable Files...................................... 95 12.7 Known Issues............................................... 96 ii 13 Download status 97 13.1 Introduction............................................... 97 13.2 What’s involved in a download?..................................... 97 13.3 Data on the download-status page.................................... 98 14 Known Issues 101 14.1 Known Issues in Tahoe-LAFS v1.10.3, released 30-Mar-2016..................... 101 14.2 Known Issues in Tahoe-LAFS v1.9.0, released 31-Oct-2011...................... 105 14.3 Known Issues in Tahoe-LAFS v1.8.2, released 30-Jan-2011...................... 105 15 Contributing to Tahoe-LAFS 107 16 Contributor Code of Conduct 109 17 Release Checklist 111 17.1 Any Contributor............................................. 111 17.2 Privileged Contributor.......................................... 113 17.3 Announcing the Release......................................... 114 18 How To Configure A Server 117 18.1 Manual Configuration.......................................... 117 18.2 Automatic Configuration......................................... 118 18.3 Deployment Scenarios.......................................... 118 19 The Tahoe Upload Helper 121 19.1 Overview................................................. 121 19.2 Setting Up A Helper........................................... 122 19.3 Using a Helper.............................................. 122 19.4 Other Helper Modes........................................... 123 20 The Convergence Secret 125 20.1 What Is It?................................................ 125 20.2 What If I Change My Convergence Secret?............................... 126 20.3 How To Use It.............................................. 126 21 Garbage Collection in Tahoe 127 21.1 Overview................................................. 127 21.2 Client-side Renewal........................................... 128 21.3 Server Side Expiration.......................................... 128 21.4 Expiration Progress........................................... 130 21.5 Future Directions............................................. 130 22 Statement on Backdoors 133 23 Donations 135 23.1 Governance................................................ 135 23.2 Transparent Accounting......................................... 135 23.3 Expenditure Addresses.......................................... 136 23.4 Historical Donation Addresses...................................... 136 23.5 Validation................................................. 136 24 Storage Server Donations 137 24.1 Sending Donations............................................ 137 24.2 Receiving Donations........................................... 138 24.3 Further Reading............................................. 138 iii 25 Expenses paid by donated BTC 139 25.1 Budget Items............................................... 139 26 Things To Be Careful About As We Venture Boldly Forth 143 26.1 Timing Attacks.............................................. 143 27 Avoiding Write Collisions in Tahoe 145 28 The Tahoe BackupDB 147 28.1 Overview................................................. 147 28.2 Schema.................................................. 148 28.3 Upload Operation............................................ 148 28.4 Directory Operations........................................... 149 29 Developer Guide 151 29.1 Pre-commit Checks........................................... 151 30 Ticket Triage 153 30.1 Process.................................................. 153 31 Using Tahoe-LAFS with an anonymizing network: Tor, I2P 155 31.1 Overview................................................. 155 31.2 Use cases................................................. 155 31.3 Software Dependencies......................................... 156 31.4 Connection configuration........................................ 157 31.5 Anonymity configuration......................................... 157 31.6 Performance and security issues..................................... 159 32 Node Keys in Tahoe-LAFS 163 32.1 Why Announcements Are Signed.................................... 163 32.2 How The Node ID Is Computed..................................... 164 32.3 Version Compatibility, Fallbacks For Old Versions........................... 164 32.4 Share Placement............................................. 164 33 Performance costs for some common operations 167 33.1 Publishing
Load more

Recommended publications
  • Guidelines and Strategies for Secure Interaction Design
    ,ch13.10831 Page 253 Friday, August 5, 2005 10:12 PM Chapter 13 CHAPTER THIRTEEN Guidelines and Strategies for Secure Interaction Design KA-PING YEE ALTHOUGH A RELIABLE, USABLE AUTHENTICATION METHOD IS ESSENTIAL, it is far from the only human interface concern. After a user signs in to a system, the system has to carry out the user’s wishes correctly in order to be considered secure. The question of secure inter- action design, addressed in this and the other chapters in this part of the book, is: How can we design a computer system to protect the interests of its legitimate user? To give you a sense of how important it is to look beyond authentication, consider some of today’s most serious security problems. Viruses are a leading contender, with email viruses making up a large part. Spyware is growing into a nightmare for home users and IT staff. Identity theft is becoming widespread, perpetrated in part through “phishing” scams in which forged email messages entice people to give away private information. None of these problems is caused by defeating a login mechanism. They would be better described as failures of computers to behave as their users expect. This chapter suggests some guidelines for designing and evaluating usable secure software and proposes two strategies for getting security and usability to work in harmony: security by designation and user-assigned identifiers. I’ll begin by providing a little background for our discussion, then present the guidelines and strategies, and finally look at real design problems to show how these strategies can be applied in practice.
    [Show full text]
  • Improving Learning of Programming Through E-Learning by Using Asynchronous Virtual Pair Programming
    Improving Learning of Programming Through E-Learning by Using Asynchronous Virtual Pair Programming Abdullah Mohd ZIN Department of Industrial Computing Faculty of Information Science and Technology National University of Malaysia Bangi, MALAYSIA Sufian IDRIS Department of Computer Science Faculty of Information Science and Technology National University of Malaysia Bangi, MALAYSIA Nantha Kumar SUBRAMANIAM Open University Malaysia (OUM) Faculty of Information Technology and Multimedia Communication Kuala Lumpur, MALAYSIA ABSTRACT The problem of learning programming subjects, especially through distance learning and E-Learning, has been widely reported in literatures. Many attempts have been made to solve these problems. This has led to many new approaches in the techniques of learning of programming. One of the approaches that have been proposed is the use of virtual pair programming (VPP). Most of the studies about VPP in distance learning or e-learning environment focus on the use of the synchronous mode of collaboration between learners. Not much research have been done about asynchronous VPP. This paper describes how we have implemented VPP and a research that has been carried out to study the effectiveness of asynchronous VPP for learning of programming. In particular, this research study the effectiveness of asynchronous VPP in the learning of object-oriented programming among students at Open University Malaysia (OUM). The result of the research has shown that most of the learners have given positive feedback, indicating that they are happy with the use of asynchronous VPP. At the same time, learners did recommend some extra features that could be added in making asynchronous VPP more enjoyable. Keywords: Pair-programming; Virtual Pair-programming; Object Oriented Programming INTRODUCTION Delivering program of Information Technology through distance learning or E- Learning is indeed a very challenging task.
    [Show full text]
  • The Joe-E Language Specification (Draft)
    The Joe-E Language Specification (draft) Adrian Mettler David Wagner famettler,[email protected] February 3, 2008 Disclaimer: This is a draft version of the Joe-E specification, and is subject to change. Sections 5 - 7 mention some (but not all) of the aspects of the Joe-E language that are future work or current works in progress. 1 Introduction We describe the Joe-E language, a capability-based subset of Java intended to make it easier to build secure systems. The goal of object capability languages is to support the Principle of Least Authority (POLA), so that each object naturally receives the least privilege (i.e., least authority) needed to do its job. Thus, we hope that Joe-E will support secure programming while remaining familiar to Java programmers everywhere. 2 Goals We have several goals for the Joe-E language: • Be familiar to Java programmers. To minimize the barriers to adoption of Joe-E, the syntax and semantics of Joe-E should be familiar to Java programmers. We also want Joe-E programmers to be able to use all of their existing tools for editing, compiling, executing, debugging, profiling, and reasoning about Java code. We accomplish this by defining Joe-E as a subset of Java. In general: Subsetting Principle: Any valid Joe-E program should also be a valid Java program, with identical semantics. This preserves the semantics Java programmers will expect, which are critical to keeping the adoption costs manageable. Also, it means all of today's Java tools (IDEs, debuggers, profilers, static analyzers, theorem provers, etc.) will apply to Joe-E code.
    [Show full text]
  • The Nizza Secure-System Architecture
    Appears in the proceedings of CollaborateCom 2005, San Jose, CA, USA The Nizza Secure-System Architecture Hermann Härtig Michael Hohmuth Norman Feske Christian Helmuth Adam Lackorzynski Frank Mehnert Michael Peter Technische Universität Dresden Institute for System Architecture D-01062 Dresden, Germany [email protected] Abstract rely on a standard OS (including the kernel) to assure their security properties. The trusted computing bases (TCBs) of applications run- To address the conflicting requirements of complete ning on today’s commodity operating systems have become functionality and the protection of security-sensitive data, extremely large. This paper presents an architecture that researchers have devised system architectures that reduce allows to build applications with a much smaller TCB. It the system’s TCB by running kernels in untrusted mode is based on a kernelized architecture and on the reuse of in a secure compartment on top of a small security kernel; legacy software using trusted wrappers. We discuss the de- security-sensitive services run alongside the OS in isolated sign principles, the architecture and some components, and compartments of their own. This architecture is widely re- a number of usage examples. ferred to as kernelized standard OS or kernelized system. In this paper, we describe Nizza, a new kernelized- system architecture. In the design of Nizza, we set out to answer the question of how small the TCB can be made. 1 Introduction We have argued in previous work that the (hardware and software) technologies needed to build small secure-system Desktop and hand-held computers are used for many platforms have become much more mature since earlier at- functions, often in parallel, some of which are security tempts [8].
    [Show full text]
  • Tahoe-LAFS Documentation Release 1.X
    Tahoe-LAFS Documentation Release 1.x The Tahoe-LAFS Developers January 19, 2017 Contents 1 Welcome to Tahoe-LAFS! 3 1.1 What is Tahoe-LAFS?..........................................3 1.2 What is “provider-independent security”?................................3 1.3 Access Control..............................................4 1.4 Get Started................................................4 1.5 License..................................................4 2 Installing Tahoe-LAFS 5 2.1 First: In Case Of Trouble.........................................5 2.2 Pre-Packaged Versions..........................................5 2.3 Preliminaries...............................................5 2.4 Install the Latest Tahoe-LAFS Release.................................6 2.5 Running the tahoe executable.....................................8 2.6 Running the Self-Tests..........................................8 2.7 Common Problems............................................9 2.8 Using Tahoe-LAFS............................................9 3 How To Run Tahoe-LAFS 11 3.1 Introduction............................................... 11 3.2 Do Stuff With It............................................. 12 3.3 Socialize................................................. 13 3.4 Complain................................................. 13 4 Configuring a Tahoe-LAFS node 15 4.1 Node Types................................................ 16 4.2 Overall Node Configuration....................................... 16 4.3 Connection Management........................................
    [Show full text]
  • Human Factors and Usability Issues Have Traditionally Played a Limited Role in Security Research and Secure Systems Development
    Security and Usability By Lorrie Faith Cranor, Simson Garfinkel ............................................... Publisher: O'Reilly Pub Date: August 2005 ISBN: 0-596-00827-9 Pages: 738 Table of Contents | Index Human factors and usability issues have traditionally played a limited role in security research and secure systems development. Security experts have largely ignored usability issues--both because they often failed to recognize the importance of human factors and because they lacked the expertise to address them. But there is a growing recognition that today's security problems can be solved only by addressing issues of usability and human factors. Increasingly, well-publicized security breaches are attributed to human errors that might have been prevented through more usable software. Indeed, the world's future cyber-security depends upon the deployment of security technology that can be broadly used by untrained computer users. Still, many people believe there is an inherent tradeoff between computer security and usability. It's true that a computer without passwords is usable, but not very secure. A computer that makes you authenticate every five minutes with a password and a fresh drop of blood might be very secure, but nobody would use it. Clearly, people need computers, and if they can't use one that's secure, they'll use one that isn't. Unfortunately, unsecured systems aren't usable for long, either. They get hacked, compromised, and otherwise rendered useless. There is increasing agreement that we need to design secure systems that people can actually use, but less agreement about how to reach this goal. Security & Usability is the first book-length work describing the current state of the art in this emerging field.
    [Show full text]
  • Comparative Studies of 10 Programming Languages Within 10 Diverse Criteria Revision 1.0
    Comparative Studies of 10 Programming Languages within 10 Diverse Criteria Revision 1.0 Rana Naim∗ Mohammad Fahim Nizam† Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Sheetal Hanamasagar‡ Jalal Noureddine§ Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Marinela Miladinova¶ Concordia University Montreal, Quebec, Canada [email protected] Abstract This is a survey on the programming languages: C++, JavaScript, AspectJ, C#, Haskell, Java, PHP, Scala, Scheme, and BPEL. Our survey work involves a comparative study of these ten programming languages with respect to the following criteria: secure programming practices, web application development, web service composition, OOP-based abstractions, reflection, aspect orientation, functional programming, declarative programming, batch scripting, and UI prototyping. We study these languages in the context of the above mentioned criteria and the level of support they provide for each one of them. Keywords: programming languages, programming paradigms, language features, language design and implementation 1 Introduction Choosing the best language that would satisfy all requirements for the given problem domain can be a difficult task. Some languages are better suited for specific applications than others. In order to select the proper one for the specific problem domain, one has to know what features it provides to support the requirements. Different languages support different paradigms, provide different abstractions, and have different levels of expressive power. Some are better suited to express algorithms and others are targeting the non-technical users. The question is then what is the best tool for a particular problem.
    [Show full text]
  • Scalability of Microkernel-Based Systems
    Scalability of Microkernel-Based Systems Zur Erlangung des akademischen Grades eines DOKTORS DER INGENIERWISSENSCHAFTEN von der Fakultat¨ fur¨ Informatik der Universitat¨ Fridericiana zu Karlsruhe (TH) genehmigte DISSERTATION von Volkmar Uhlig aus Dresden Tag der mundlichen¨ Prufung:¨ 30.05.2005 Hauptreferent: Prof. Dr. rer. nat. Gerhard Goos Universitat¨ Fridericiana zu Karlsruhe (TH) Korreferent: Prof. Dr. sc. tech. (ETH) Gernot Heiser University of New South Wales, Sydney, Australia Karlsruhe: 15.06.2005 i Abstract Microkernel-based systems divide the operating system functionality into individ- ual and isolated components. The system components are subject to application- class protection and isolation. This structuring method has a number of benefits, such as fault isolation between system components, safe extensibility, co-existence of different policies, and isolation between mutually distrusting components. How- ever, such strict isolation limits the information flow between subsystems including information that is essential for performance and scalability in multiprocessor sys- tems. Semantically richer kernel abstractions scale at the cost of generality and mini- mality–two desired properties of a microkernel. I propose an architecture that al- lows for dynamic adjustment of scalability-relevant parameters in a general, flex- ible, and safe manner. I introduce isolation boundaries for microkernel resources and the system processors. The boundaries are controlled at user-level. Operating system components and applications can transform their semantic information into three basic parameters relevant for scalability: the involved processors (depending on their relation and interconnect), degree of concurrency, and groups of resources. I developed a set of mechanisms that allow a kernel to: 1. efficiently track processors on a per-resource basis with support for very large number of processors, 2.
    [Show full text]
  • Concepts of Programming Languages, Eleventh Edition, Global Edition
    GLOBAL EDITION Concepts of Programming Languages ELEVENTH EDITION Robert W. Sebesta digital resources for students Your new textbook provides 12-month access to digital resources that may include VideoNotes (step-by-step video tutorials on programming concepts), source code, web chapters, quizzes, and more. Refer to the preface in the textbook for a detailed list of resources. Follow the instructions below to register for the Companion Website for Robert Sebesta’s Concepts of Programming Languages, Eleventh Edition, Global Edition. 1. Go to www.pearsonglobaleditions.com/Sebesta 2. Click Companion Website 3. Click Register and follow the on-screen instructions to create a login name and password Use a coin to scratch off the coating and reveal your access code. Do not use a sharp knife or other sharp object as it may damage the code. Use the login name and password you created during registration to start using the digital resources that accompany your textbook. IMPORTANT: This access code can only be used once. This subscription is valid for 12 months upon activation and is not transferable. If the access code has already been revealed it may no longer be valid. For technical support go to http://247pearsoned.custhelp.com This page intentionally left blank CONCEPTS OF PROGRAMMING LANGUAGES ELEVENTH EDITION GLOBAL EDITION This page intentionally left blank CONCEPTS OF PROGRAMMING LANGUAGES ELEVENTH EDITION GLOBAL EDITION ROBERT W. SEBESTA University of Colorado at Colorado Springs Global Edition contributions by Soumen Mukherjee RCC Institute
    [Show full text]
  • PROGRAMMING LANGUAGES TENTH EDITION This Page Intentionally Left Blank CONCEPTS of PROGRAMMING LANGUAGES TENTH EDITION
    CONCEPTS OF PROGRAMMING LANGUAGES TENTH EDITION This page intentionally left blank CONCEPTS OF PROGRAMMING LANGUAGES TENTH EDITION ROBERT W. SEBESTA University of Colorado at Colorado Springs Boston Columbus Indianapolis New York San Francisco Upper Saddle River Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montreal Toronto Delhi Mexico City Sao Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo Vice President and Editorial Director, ECS: Senior Production Project Manager: Marilyn Lloyd Marcia Horton Manufacturing Manager: Nick Sklitsis Editor in Chief: Michael Hirsch Operations Specialist: Lisa McDowell Executive Editor: Matt Goldstein Cover Designer: Anthony Gemmellaro Editorial Assistant: Chelsea Kharakozova Text Designer: Gillian Hall Vice President Marketing: Patrice Jones Cover Image: Mountain near Pisac, Peru; Marketing Manager: Yez Alayan Photo by author Marketing Coordinator: Kathryn Ferranti Media Editor: Dan Sandin Marketing Assistant: Emma Snider Full-Service Vendor: Laserwords Vice President and Director of Production: Project Management: Gillian Hall Vince O’Brien Printer/Binder: Courier Westford Managing Editor: Jeff Holcomb Cover Printer: Lehigh-Phoenix Color This book was composed in InDesign. Basal font is Janson Text. Display font is ITC Franklin Gothic. Copyright © 2012, 2010, 2008, 2006, 2004 by Pearson Education, Inc., publishing as Addison-Wesley. All rights reserved. Manufactured in the United States of America. This publication is protected by Copy- right, and permission should be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. To obtain permission(s) to use material from this work, please submit a written request to Pearson Education, Inc., Permissions Department, One Lake Street, Upper Saddle River, New Jersey 07458, or you may fax your request to 201-236-3290.
    [Show full text]
  • Genode Operating System Framework Platforms
    GENODE Operating System Framework 21.05 Platforms Norman Feske Contents Contents 1 Introduction3 2 Porting Genode to a new SoC4 2.1 Preparatory steps................................9 2.1.1 Licensing considerations........................9 2.1.2 Selecting a suitable SoC........................ 10 2.1.3 Start by taking the known-good path................ 11 2.1.4 Setting up an efficient development workflow........... 12 2.2 Getting acquainted with the target platform................. 14 2.2.1 Getting a first impression....................... 15 2.2.2 The U-Boot boot loader........................ 19 2.3 Bare-metal serial output............................ 24 2.4 Kernel skeleton................................. 34 2.4.1 A tour through the code base..................... 34 2.4.2 A new home for the board support.................. 41 2.4.3 Getting to grips using meaningful numbers............. 48 2.4.4 A first life sign of the kernel...................... 55 2.5 Low-level debugging.............................. 57 2.5.1 Option 1: Walking the source code.................. 58 2.5.2 Option 2: One step of ground truth at a time............ 60 2.5.3 Option 3: Backtraces.......................... 62 2.6 Excursion to the user land........................... 64 2.7 Device access from the user level....................... 73 2.7.1 Using a GPIO pin for sensing a digital signal............ 74 2.7.2 Driving an LED via a GPIO pin.................... 81 2.7.3 Responding to device interrupts................... 84 2.8 One Platform driver to rule them all..................... 90 2.8.1 Platform driver............................. 90 2.8.2 Session interfaces for accessing pins................. 95 2.8.3 PIO device driver............................ 96 2.8.4 Dynamic configuration testing...................
    [Show full text]
  • Genode Operating System Framework Foundations
    GENODE Operating System Framework 15.05 Foundations Norman Feske Contents Contents 1. Introduction9 1.1. Operating-system framework......................... 14 1.2. Licensing and commercial support...................... 16 1.3. About this document.............................. 17 I. Foundations 18 2. Getting started 19 2.1. Obtaining the source code........................... 20 2.2. Source-tree structure.............................. 21 2.3. Using the build system............................. 24 2.4. A simple system scenario........................... 26 2.5. Hello world................................... 29 2.5.1. Using a custom source-code repository............... 29 2.5.2. Source code and build description.................. 29 2.5.3. Building the component........................ 30 2.5.4. Defining a system scenario...................... 31 3. Architecture 33 3.1. Capability-based security........................... 35 3.1.1. Capability spaces, object identities, and RPC objects........ 35 3.1.2. Delegation of authority and ownership............... 36 3.1.3. Capability invocation......................... 37 3.1.4. Capability delegation through capability invocation........ 40 3.2. Recursive system structure........................... 42 3.2.1. Component ownership......................... 42 3.2.2. Tree of components........................... 43 3.2.3. Services and sessions.......................... 43 3.2.4. Client-server relationship....................... 46 3.3. Resource trading................................ 50 3.3.1. Resource
    [Show full text]