COS 318: Operating Systems. File Systems: Networked, Abstractions and Protection. Topics. Evolved Data Center Storage Hierarchy

Transcription

1 Topics COS 18: Operating Systems Fie Systems: Networked, Abstractions and Protection What s behind the fie system: Networked hierarchy More on the fie system abstraction Fie system protection Jaswinder Pa Singh Computer Science Department Princeton University ( Traditiona Data Center Hierarchy Evoved Data Center Hierarchy Cients LAN Server SAN Remote mirror Cients LAN Network Attached (NAS) w/ snapshots to protect data Remote mirror Onsite Backup Offsite backup Onsite Backup Offsite backup 4 5 1

2 Aternative with no Tape Pubic Coud Hierarchy LAN Remote mirror w/ snapshots to protect data Cients Network Attached (NAS) Cients Remote Backup Onsite Backup Dedupication Capacity and bandwidth optimization Interfaces Geo-pex Exampes: Googe GFS, Spanner, Appe icoud, Amazon S, Dropbox, Mozy, etc 6 NFS Protocos Network Fie System u u 7 Mutipe cients share an NFS server NFS v2 was introduced in eary 80s u Mounting Network NFS server u Cients NFS server can expose directories for remote access Cient sends a mount request with path name to server Server returns a hande (fie system type, disk, i-node of directory, security information) Automount / /dev /u/cos126 /bin /u/cos18 Cient Directory and fie accesses proj No open and cose Use handes to read and write 1 7 /u 2 Server 8 2

3 NFS Protoco (v) NFS Architecture 1. NULL: Do nothing 2. GETATTR: Get fie attributes. SETATTR: Set fie attributes 4. LOOKUP: Lookup fiename 5. ACCESS: Check Access Permission 6. READLINK: Read from symboic ink 7. READ: Read From fie 8. WRITE: Write to fie 9. CREATE: Create a fie 10. MKDIR: Create a directory 11. SYMLINK: Create a symboic ink 12. MKNOD: Create a specia device 1. REMOVE: Remove a Fie 14. RMDIR: Remove a Directory 15. RENAME: Rename a Fie or Directory 16. LINK: Create Link to an object 17. READDIR: Read From Directory 18. READDIRPLUS: Extended read from directory 19. FSSTAT: Get dynamic fie system information 20. FSINFO: Get static fie system Information 21. PATHCONF: Retrieve POSIX information 22. COMMIT: Commit cached data on a server to stabe storage 9 Loca FS NFS Server Virtua fie system Loca FS Buffer cache NFS server Network NFS cient Cient kerne Virtua fie system Loca FS Buffer cache Loca FS 10 NFS Cient Caching Issues u Consistency among mutipe cient caches Cient cache contents may not be up-to-date Mutipe writes can happen simutaneousy u Soutions Expiration Read-ony fie and directory data (expire in 60 seconds) Data written by the cient machine (write back in 0 seconds) No shared caching A fie can be cached at ony one cient cache Network ock manager Sequentia consistency (one writer or N readers) NFS Protoco Deveopment u Version 2 issues 18 operations Size: imit to 4GB fie size Write performance: server writes data synchronousy Severa other issues u Version changes (most products sti use this) 22 operations Size: increase to 64 bit Write performance: WRITE and COMMIT Fixed severa other issues Sti stateess u Version 4 changes 42 operations Sove the consistency issues Security issues Statefu 11 12

4 Topics Revisit Fie System Abstractions What s behind the fie system: networked storage hierarchy More on the fie system abstraction Fie system protection Network fie system Map to oca fie systems Exposes fie system API NFS, CIFS, etc Loca fie system Impement fie system abstraction on bock storage Exposes fie system API Voume manager Logica voumes of bock storage Map to physica storage RAID and reconstruction Exposes bock API Physica storage Previous ectures Network Fie System Loca Fie System Voume Manager Physica storage 8 Voume Manager Fie versus Bock Abstractions Group mutipe storage partitions into a ogica voume Virtuaization of capacity and performance No need to dea with physica disk or sector numbers Read(vo#, bock#, buf, n) Reiabe bock storage Incude RAID, toerating device faiures Provide error detection at bock eve Remote abstraction Bock storage in the coud Remote voumes for disaster recovery Remote mirrors can be spit or merged for backups How to impement? OS kerne: Windows, OSX, Linux, etc. subsystem: EMC, Hitachi, HP, IBM, NetApp Fie abstraction Byte oriented Named fies Users protected from each other Robust to machine faiures Emuate bock storage interface Disk/Voume abstraction Bock oriented Bock numbers No protection among users of the system Data might be corrupted if machine crashes Support fie systems, database systems, etc

5 Fie Abstraction: Fie Structures Fie Abstraction: Fie Types Byte sequence Read or write N bytes Unstructured or inear Record sequence Fixed or variabe ength Read or write a number of records Tree Records with keys Read, insert, deete a record (typicay using B-tree) ASCII Binary data Record Tree An Unix executabe fie header: magic number, sizes, entry point, fags text data reocation bits symbo tabe Devices Character specia fies (to mode terminas, printers) Bock specia fies (to mode disks) Everything ese in the system Fie Abstraction: Fie Operations Operations for sequence of bytes fies Create: create a fie (mapping from a name to a fie) Deete: deete a fie Open: incuding authentication Cose: done with accessing a fie Seek: jump to a particuar ocation in a fie Read: read some bytes from a fie Write: write some bytes to a fie A few more operations on directories: ater Impementation chaenges Keep disk accesses ow Keep space overhead ow Fie system abstraction u Directory Group of named fies or subdirectories Mapping from fie name to fie metadata ocation u Path String that uniquey identifies fie or directory Ex: /cse/www/education/courses/ cse451/12au u Links Hard ink: ink from name to metadata ocation Soft ink: ink from name to aternate name u Mount Mapping from name in one fie system to root of another 1 5

6 Fie Access Patterns Sequentia (the common pattern) Fie data processed sequentiay Exampe: Editor writes out a fie Random access Access a bock in fie directy Exampe: Read a message in an inbox fie Keyed access Search for a record with particuar vaues Usuay not provided by today s fie systems Exampes: Database search and indexing Fie System vs. Virtua Memory Simiarity Location transparency Size "obiviousness" Protection Fie system is easier than VM in some ways Fie system mappings can be sow Fies are dense and mosty sequentia, whie page tabes dea with sparse address spaces and random accesses Fie system is more difficut than VM in some ways Each ayer of transation causes potentia I/Os Memory space for caching is never enough Fie size range vary: many < 10k, some > GB Impementation must be reiabe VM Page Tabe vs. Fie System Metadata Topics Page tabe Manage the mappings of an address space Map virtua page # to physica page # Check access permission and iega addressing TLB does it a in one cyce Fie metadata Manage the mappings of fies Map byte offset to disk bock address Check access permission and iega addressing Impemented in software, may cause I/Os What s behind the fie system: hierarchy More on fie system abstraction Fie system protection 15 6

7 Protection: Poicy vs. Mechanism Poicy is about what Mechanism is about how A protection system is the mechanism to enforce a security poicy Same set of choices, no matter what poicies A security poicy defines acceptabe and unacceptabe behaviors. Exampes: A given user can ony aocate 4GB of disk storage No one but root can write to the password fie A user is not aowed to read others mai fies Protection Mechanisms Authentication Identity check Unix: password Credit card: ast 4 digits of credit card # + SSN + zipcode Airport: driver s icense or passport Authorization Determine if x is aowed to do y Need a simpe database Access enforcement Enforce authorization decision Must make sure there are no oophoes Authentication Usuay done with passwords Reativey weak, because you must remember them Passwords are stored in an encrypted form Use a secure hash (one way ony) Issues Passwords shoud be obscure, to prevent dictionary attacks Each user has many passwords Aternatives? Protection Domain Once identity known, provides rues E.g. what is Bob aowed to do? E.g. who can do what to fie A? Protection matrix: domains vs. resources Fie A Printer B Fie C Domain 1 R W RW Domain 2 RW W Domain R RW

8 By Coumns: Access Contro Lists (ACLs) Each object has a ist of <user, priviege> pairs ACL is simpe, impemented in most systems Owner, group, word Impementation considerations Stores ACLs in each fie Use ogin authentication to identify Kerne impements ACLs Any issues? By Rows: Capabiities For each user, there is a capabiity ist A ists of <object, priviege> pairs Capabiities provide both naming and protection Can ony see an object if you have a capabiity Impementation considerations Architecture support Capabiities stored in the kerne Capabiities stored in the user space in encrypted format Issues? Access Enforcement Use a trusted party to Enforce access contros Protect authorization information Kerne is the trusted party This part of the system can do anything it wants If there is a bug, the entire system coud be destroyed Want it to be as sma & simpe as possibe Security is ony as strong as the weakest ink in the protection system Some Easy Attacks Abuse of vaid priviege On Unix, super-user can do anything Read your mai, send mai in your name, etc. If you deete the code for COS18 project 5, your partner is not happy Spoier/Denia of service (DoS) Use up a resources and make system crash Run she script to: whie(1) { mkdir foo; cd foo; } Listener Passivey watch network traffic

9 No Perfect Protection System Cannot prevent bad things, can ony make it difficut to do them There are aways ways to defeat protection burgary, bribery, backmai, budgeoning, etc. Every system has hoes Summary hierarchy can be compex Reiabiity, security, performance and cost Many things are hidden Key storage ayers above hardware Voume or bock storage Loca fie system Network fie system Protection ACL is the defaut in fie systems More protection is needed in the coud