1

COS 318: Operating Systems

File Systems: Networked, Abstractions and Protection

Jaswinder Pal Singh and a Fabulous Course StaffComputer Science DepartmentPrinceton University

(http://www.cs.princeton.edu/courses/cos318/)

1

3

Topics◆ What’s behind the file system: Networked Storage

hierarchy◆ More on the file system abstraction◆ File system protection

2

4

Traditional Data Center Storage Hierarchy

LAN SAN

Clients Server

…

Storage

Storage

OnsiteBackup

Offsitebackup

WAN

Remotemirror

3

5

Evolved Data Center Storage Hierarchy

LAN

Clients

Storage

…

OnsiteBackup

Offsitebackup

Remotemirror

NetworkAttachedStorage(NAS)

w/ snapshotsto protect data

WAN

4

2

6

Alternative with no Tape

LAN

Clients

…

OnsiteBackup

WAN

Remotemirror

NetworkAttachedStorage(NAS)

w/ snapshotsto protect data

WAN

RemoteBackup

“Deduplication”Capacity andbandwidth optimization

5

7

“Public Cloud” Storage Hierarchy

WAN

Clients

… WANInterfaces Geo-plex

Examples: Google GFS, Spanner, Apple Cloud, Amazon S3, Box,Dropbox, Mozy, etc

6

7

Network File Systemu Multiple clients share an NFS serveru NFS v2 was introduced in early 80s

Network

NFS server

Clients

7

NFS Protocols

u Mountingl NFS server can expose

directories for remote accessl Client sends a mount request

with path name to serverl Server returns a handle (file

system type, disk, i-node of directory, security information)

l Automountu Directory and file accesses

l No open and closel Use handles to read and write

8

proj

1 2 3 Server

/

/u /bin/dev

/u/cos126 /u/cos318

Client

8

3

9

NFS Protocol (v3)1. NULL: Do nothing2. GETATTR: Get file attributes3. SETATTR: Set file attributes4. LOOKUP: Lookup filename5. ACCESS: Check Access Permission6. READLINK: Read from symbolic link7. READ: Read From file8. WRITE: Write to file9. CREATE: Create a file10. MKDIR: Create a directory11. SYMLINK: Create a symbolic link12. MKNOD: Create a special device13. REMOVE: Remove a File14. RMDIR: Remove a Directory15. RENAME: Rename a File or Directory16. LINK: Create Link to an object17. READDIR: Read From Directory18. READDIRPLUS: Extended read from directory19. FSSTAT: Get dynamic file system information20. FSINFO: Get static file system Information21. PATHCONF: Retrieve POSIX information22. COMMIT: Commit cached data on a server to

stable storage

9

10

NFS Architecture

Virtual file system

Client kernel

LocalFS

LocalFS

NFSclient

Buffer cache

Virtual file system

LocalFS

LocalFS

NFSserver

Buffer cache

NFS Server

Network

10

11

NFS Client Caching Issuesu Consistency among multiple client caches

l Client cache contents may not be up-to-datel Multiple writes can happen simultaneously

u Solutionsl Expiration

• Read-only file and directory data (expire in 60 seconds)• Data written by the client machine (write back in 30 seconds)

l No shared caching• A file can be cached at only one client cache

l Network lock manager• Sequential consistency (one writer or N readers)

11

12

NFS Protocol Developmentu Version 2 issues

l 18 operationsl Size: limit to 4GB file sizel Write performance: server writes data synchronouslyl Several other issues

u Version 3 changes (a lot of products still use this)l 22 operationsl Size: increase to 64 bitl Write performance: WRITE and COMMITl Fixed several other issuesl Still stateless

u Version 4 changesl 42 operationsl Solve the consistency issuesl Stateful

12

4

3

Topics◆ What’s behind the file system: networked storage

hierarchy◆ More on the file system abstraction◆ File system protection

13

Physical storage

8

Revisit File System Abstractions◆ Network file system

l Map to local file systemsl Exposes file system APIl NFS, CIFS, etc

◆ Local file systeml Implement file system abstraction on

block storagel Exposes file system API

◆ Volume managerl Logical volumes of block storagel Map to physical storage l RAID and reconstructionl Exposes block API

◆ Physical storagel Previous lectures

Volume Manager

Local File System

Network File System

14

Volume Manager◆ Group multiple storage partitions into a logical volume

l Virtualization of capacity and performance ◆ No need to deal with physical disk or sector numbers

◆ Read(vol#, block#, buf, n)◆ Reliable block storage

l Include RAID, tolerating device failuresl Provide error detection at block level

◆ Remote abstractionl Block storage in the cloudl Remote volumes for disaster recoveryl Remote mirrors can be split or merged for backups

◆ How to implement?l OS kernel: Windows, OSX, Linux, etc.l Storage subsystem: EMC, Hitachi, HP, IBM, NetApp

9

15

10

File versus Block Abstractions

Disk/Volume abstraction◆ Block oriented◆ Block numbers◆ No protection among users of

the system◆ Data might be corrupted if

machine crashes

◆ Support file systems, database systems, etc.

File abstraction◆ Byte oriented◆ Named files◆ Users protected from each

other◆ Robust to machine failures

◆ Emulate block storage interface

16

5

11

File Abstraction: File Structures◆ Byte sequence

l Read or write N bytesl Unstructured or linear

◆ Record sequencel Fixed or variable lengthl Read or write a number of

records◆ Tree

l Records with keysl Read, insert, delete a record

(typically using B-tree)…

… … …

17

12

File Abstraction: File Types◆ ASCII◆ Binary data

l Recordl Treel An Unix executable file

• header: magic number, sizes, entry point, flags• text• data• relocation bits• symbol table

◆ Devices◆ Character special files (to model terminals, printers)◆ Block special files (to model disks)

◆ Everything else in the system

18

13

File Abstraction: File Operations

◆ Operations for “sequence of bytes” filesl Create: create a file (mapping from a name to a file)l Delete: delete a filel Open: including authenticationl Close: done with accessing a filel Seek: jump to a particular location in a filel Read: read some bytes from a filel Write: write some bytes to a filel A few more operations on directories: later

◆ Implementation challengesl Keep disk accesses lowl Keep space overhead low

19

File Access Patterns

◆ Sequential (the common pattern)l File data processed sequentiallyl Example: Editor writes out a file

◆ Random accessl Access a block in file directlyl Example: Read a message in an inbox file

◆ Keyed accessl Search for a record with particular valuesl Usually not provided by today’s file systemsl Examples: Database search and indexing

14

20

6

File system abstraction

u Directoryl Group of named files or subdirectoriesl Mapping from file name to file metadata location

u Pathl String that uniquely identifies file or directoryl Ex: /cse/www/education/courses/cse451/12au

u Linksl Hard link: link from name to metadata locationl Soft link: link from name to alternate name

u Mountl Mapping from name in one file system to root of another

21

16

File System vs. Virtual Memory◆ Similarity

l Location transparencyl Size "obliviousness"l Protection

◆ File system is easier than VM in some waysl File system mappings can be slowl Files are dense and mostly sequential, while page tables deal

with sparse address spaces and random accesses

◆ File system is more difficult than VM in some waysl Each layer of translation causes potential I/Osl Memory space for caching is never enoughl File size range vary: many < 10k, some > GBl Implementation must be reliable

22

15

VM Page Table vs. File System Metadata

Page table◆ Manage the mappings of an

address space◆ Map virtual to physical page #◆ Check access permission and

illegal addressing◆ TLB does it all in one cycle

File metadata◆ Manage the mappings of files◆ Map byte offset to disk block

address◆ Check access permission and illegal

addressing◆ Implemented in software, may

cause I/Os

23

3

Topics◆ What’s behind the file system: Storage hierarchy◆ More on file system abstraction◆ File system protection

24

7

17

Protection: Policy vs. Mechanism

◆ Policy is about what◆ Mechanism is about how◆ A security policy defines acceptable and unacceptable

behaviors. Examples: • A given user can only allocate 4GB of disk storage• No one but root can write to the password file• A user is not allowed to read others’mail files

◆ A protection system is the mechanism to enforce a security policy l Same set of choices, no matter what policies

u Principle of least privilege

25

18

Protection Mechanisms

◆ Authenticationl Identity check

• Unix: password• Credit card: last 4 digits of credit card # + SSN + zipcode• Airport: driver’s license or passport

◆ Authorizationl Determine if x is allowed to do yl Need a simple database

◆ Access enforcementl Enforce authorization decisionl Must make sure there are no loopholes

26

19

Authentication

◆ Usually done with passwords l Relatively weak, because you must remember them

◆ Passwords are stored in an encrypted forml Use a “secure hash” (one way only)

◆ Issuesl Passwords should be obscure, to prevent “dictionary

attacks”l Each user has many passwords

◆ Alternatives?

27

20

Protection Domain◆ Once identity known, provides rules

l E.g. what is Bob allowed to do?l E.g. who can do what to file A?

◆ Protection matrix: domains and resources

File A Printer B File C

Domain 1 R W RW

Domain 2 RW W …

Domain 3 R … RW

28

8

21

By Columns: Access Control Lists (ACLs)

◆ Each object has a list of<user, privilege> pairs

◆ ACL is simple, implemented in most systemsl Owner, group, world

◆ Implementation considerationsl Stores ACLs in each filel Use login authentication to identifyl Kernel implements ACLs

◆ Any issues?

29

22

By Rows: Capabilities◆ For each user, there is a capability list

l A lists of <object, privilege> pairs

◆ Capabilities provide both naming and protectionl Can only “see” an object if you have a capability

◆ Implementation considerationsl Architecture supportl Capabilities stored in the kernell Capabilities stored in the user space in encrypted format

◆ Issues?

30

23

Access Enforcement◆ Use a trusted party to

l Enforce access controlsl Protect authorization information

◆ Kernel is the trusted partyl This part of the system can do anything it wantsl If there is a bug, the entire system could be destroyedl Want it to be as small & simple as possible

◆ Security is only as strong as the weakest link in the protection system

31

24

Some Easy Attacks

◆ Abuse of valid privilegel On Unix, super-user can do anything

• Read your mail, send mail in your name, etc. l If you delete the code for COS318 project 5, your partner is not

happy

◆ Spoiler/Denial of service (DoS)l Use up all resources and make system crashl Run shell script to: “while(1) { mkdir foo; cd foo; }”

◆ Listenerl Passively watch network traffic

32

9

No Perfect Protection System

◆ Cannot prevent bad things, can only make it difficult to do them

◆ There are always ways to defeat protectionl burglary, bribery, blackmail, bludgeoning, etc.

◆ Every system has holes

25

33

26

Summary

◆ Storage hierarchy can be complexl Reliability, security, performance and costl Many things are hidden

◆ Key storage layers above hardwarel Volume or block storagel Local file systeml Network file system

◆ Protectionl ACL is the default in file systemsl More protection is needed in the cloud

34