CS162 Operating Systems and Systems Programming Lecture 21 Networking April 8, 2010 Ion Stoica http://inst.eecs.berkeley.edu/~cs162Lec 21.2 4/8/10 CS162 ©UCB Spring 2010 Goals for Today • Distributed file systems • Authorization • Networking – Broadcast – Point-to-Point Networking – Routing – Internet Protocol (IP) Note: Some slides and/or pictures in the following are adapted from slides ©2005 Silberschatz, Galvin, and Gagne Note: Some slides and/or pictures in the following are adapted from slides ©2005 Silberschatz, Galvin, and Gagne. Many slides generated from lecture notes by Kubiatowicz.Lec 21.3 4/8/10 CS162 ©UCB Spring 2010 Remote File Systems: Virtual File System (VFS) • VFS: Virtual abstraction similar to local file system – Instead of “inodes” has “vnodes” – Compatible with a variety of local and remote file systems » provides object-oriented way of implementing file systems • VFS allows the same system call interface (the API) to be used for different types of file systems – The API is to the VFS interface, rather than any specific type of file systemLec 21.4 4/8/10 CS162 ©UCB Spring 2010 Network File System (NFS) • Three Layers for NFS system – UNIX file-system interface: open, read, write, close calls + file descriptors – VFS layer: distinguishes local from remote files » Calls the NFS protocol procedures for remote requests – NFS service layer: bottom layer of the architecture » Implements the NFS protocol • NFS Protocol: remote procedure calls (RPC) for file operations on server – Reading/searching a directory – manipulating links and directories – accessing file attributes/reading and writing files • NFS servers are stateless; each request provides all arguments require for execution • Modified data must be committed to the server’s disk before results are returned to the client – lose some of the advantages of caching – Can lead to weird results: write file on one client, read on other, get old dataLec 21.5 4/8/10 CS162 ©UCB Spring 2010 Schematic View of NFS ArchitectureLec 21.6 4/8/10 CS162 ©UCB Spring 2010 Authorization: Who Can Do What? • How do we decide who is authorized to do actions in the system? • Access Control Matrix: contains all permissions in the system – Resources across top » Files, Devices, etc… – Domains in columns » A domain might be a user or a group of users » E.g. above: User D3 can read F2 or execute F3 – In practice, table would be huge and sparse!Lec 21.7 4/8/10 CS162 ©UCB Spring 2010 Authorization: Two Implementation Choices • Access Control Lists: store permissions with object – Still might be lots of users! – UNIX limits each file to: r,w,x for owner, group, world – More recent systems allow definition of groups of users and permissions for each group – ACLs allow easy changing of an object’s permissions » Example: add Users C, D, and F with rw permissions • Capability List: each process tracks which objects has permission to touch – Popular in the past, idea out of favor today – Consider page table: Each process has list of pages it has access to, not each page has list of processes … – Capability lists allow easy changing of a domain’s permissions » Example: you are promoted to system administrator and should be given access to all system filesLec 21.8 4/8/10 CS162 ©UCB Spring 2010 Authorization: Combination Approach • Users have capabilities, called “groups” or “roles” – Everyone with particular group access is “equivalent” when accessing group resource – Like passport (which gives access to country of origin) • Objects have ACLs – ACLs can refer to users or groups – Change object permissions object by modifying ACL – Change broad user permissions via changes in group membership – Possessors of proper credentials get accessLec 21.9 4/8/10 CS162 ©UCB Spring 2010 Authorization: How to Revoke? • How does one revoke someone’s access rights to a particular object? – Easy with ACLs: just remove entry from the list – Takes effect immediately since the ACL is checked on each object access • Harder to do with capabilities since they aren’t stored with the object being controlled: – Not so bad in a single machine: could keep all capability lists in a well-known place (e.g., the OS capability table). – Very hard in distributed system, where remote hosts may have crashed or may not cooperate (more in a future lecture)Lec 21.10 4/8/10 CS162 ©UCB Spring 2010 Revoking Capabilities • Various approaches to revoking capabilities: – Put expiration dates on capabilities and force reacquisition – Put epoch numbers on capabilities and revoke all capabilities by bumping the epoch number (which gets checked on each access attempt) – Maintain back pointers to all capabilities that have been handed out (Tough if capabilities can be copied) – Maintain a revocation list that gets checked on every access attemptLec 21.11 4/8/10 CS162 ©UCB Spring 2010 Centralized vs Distributed Systems • Centralized System: System in which major functions are performed by a single physical computer – Originally, everything on single computer – Later: client/server model • Distributed System: physically separate computers working together on some task – Early model: multiple servers working together » Probably in the same room or building » Often called a “cluster” – Later models: peer-to-peer/wide-spread collaboration Server Client/Server Model Peer-to-Peer ModelLec 21.12 4/8/10 CS162 ©UCB Spring 2010 Distributed Systems: Motivation/Issues • Why do we want distributed systems? – Cheaper and easier to build lots of simple computers – Easier to add power incrementally – Users can have complete control over some components – Collaboration: Much easier for users to collaborate through network resources (such as network file systems) • The promise of distributed systems: – Higher availability: one machine goes down, use another – Better durability: store data in multiple locations – More security: each piece easier to make secure • Reality has been disappointing – Worse availability: depend on every machine
View Full Document
Unlocking...