CS162 Operating Systems and Systems Programming Lecture 21 Networking April 8 2010 Ion Stoica http inst eecs berkeley edu cs162 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 Gagne Many slides generated from lecture notes by Kubiatowicz 4 8 10 CS162 UCB Spring 2010 Lec 21 2 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 system 4 8 10 CS162 UCB Spring 2010 Lec 21 3 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 data 4 8 10 CS162 UCB Spring 2010 Lec 21 4 Schematic View of NFS Architecture 4 8 10 CS162 UCB Spring 2010 Lec 21 5 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 4 8 10 CS162 UCB Spring 2010 Lec 21 6 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 files 4 8 10 CS162 UCB Spring 2010 Lec 21 7 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 4 8 10 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 access CS162 UCB Spring 2010 Lec 21 8 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 4 8 10 CS162 UCB Spring 2010 Lec 21 9 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 attempt 4 8 10 CS162 UCB Spring 2010 Lec 21 10 Centralized vs Distributed Systems Server Client Server Model Peer to Peer Model 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 4 8 10 CS162 UCB Spring 2010 Lec 21 11 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 being up Lamport a distributed system is one where I can t do work because some machine I ve never heard of isn t working Worse reliability can lose data if any machine crashes Worse security anyone in world can break into system Coordination is more difficult Must coordinate multiple copies of shared state information using only a network What would be easy in a centralized system becomes a lot more difficult 4 8 10 CS162 UCB Spring 2010 Lec 21 12 Distributed Systems Goals Requirements Transparency the ability of the system to mask its complexity behind a simple interface Possible transparencies Location Can t tell where resources are located Migration Resources may move without the user knowing Replication Can t tell how many copies of resource exist Concurrency Can t tell how many users there are Parallelism System may speed up large jobs by spliting them into smaller pieces Fault Tolerance
View Full Document
Unlocking...