1. spcl.inf.ethz.ch @spcl_eth S ALVATORE DI G IROLAMO (TA) Networks and Operating Systems: Exercise Session 3

2. spcl.inf.ethz.ch @spcl_eth Access Control

3. spcl.inf.ethz.ch @spcl_eth Protection  File owner/creator should be able to control:  what can be done  by whom  Types of access  Read  Write  Execute  Append  Delete  List

4. spcl.inf.ethz.ch @spcl_eth Access control matrix ABCDEFGHJ… Read  Write  Append  Execute  Delete  List  … Principals Rights For a single file or directory: Problem: how to scalably represent this matrix?

5. spcl.inf.ethz.ch @spcl_eth Row-wise: ACLs  Access Control Lists  For each right, list the principals  Store with the file  Good:  Easy to change rights quickly  Scales to large numbers of files  Bad:  Doesn’t scale to large numbers of principals

6. spcl.inf.ethz.ch @spcl_eth Column-wise: Capabilities  Each principal with a right on a file holds a capability for that right  Stored with principal, not object (file)  Cannot be forged or (sometimes) copied  Good:  Very flexible, highly scalable in principals  Access control resources charged to principal  Bad:  Revocation: hard to change access rights (need to keep track of who has what capabilities)

7. spcl.inf.ethz.ch @spcl_eth POSIX (Unix) Access Control  Simplifies ACLs: each file identifies 3 principals:  Owner (a single user)  Group (a collection of users, defined elsewhere)  The World (everyone)  For each principal, file defines 3 rights:  Read (or traverse, if a directory)  Write (or create a file, if a directory)  Execute (or list, if a directory)

8. spcl.inf.ethz.ch @spcl_eth Directory implementation  Linear list of (file name, block pointer) pairs  Simple to program  Lookup is slow for lots of files (linear scan)  Hash Table – linear list with closed hashing.  Fast name lookup  Collisions  Fixed size  B-Tree – name index, leaves are block pointers  Increasingly common  Complex to maintain, but scales well

9. spcl.inf.ethz.ch @spcl_eth File types  Other file types treated “specially” by the OS  Simple, common cases:  Executable files  Directories, symbolic links, other file system data  Some distinguish between text and binary  Some have many types  “Document” or “media” types  Used to select default applications, editors, etc. True/False: The type of a file determines which kinds of operations can be performed on it. A file type is a description of the information contained in the file. A file extension is a part of the file name that follows a dot and identifies the file type. Which is the difference between a file type and a file extension? How executable files are recognized? Magic number, #! for scripts in Unix

10. spcl.inf.ethz.ch @spcl_eth Open File Interface

11. spcl.inf.ethz.ch @spcl_eth Byte-sequence files  File is a vector of bytes  Can be appended to  Can be truncated  Can be updated in place  Typically no “insert”  Accessed as:  Sequential files (rare these days)  Random access

12. spcl.inf.ethz.ch @spcl_eth Random access  Support read, write, seek, and tell  State: current position in file  Seek absolute or relative to current position.  Tell returns current index  Index units:  For byte sequence files, offset in bytes Random access vs

13. spcl.inf.ethz.ch @spcl_eth Memory-mapped files  Basic idea: use VM system to cache files  Map file content into virtual address space  Set the backing store of region to file  Can now access the file using load/store  When memory is paged out  Updates go back to file instead of swap space

14. spcl.inf.ethz.ch @spcl_eth File system implementations FATFFSNTFSZFS Index structure Linked listFixed, asymmetric tree Dynamic treeDynamic COW tree Index granularity Block ExtentBlock Free space management FAT arrayFixed bitmapBitmap in fileLog-structured space map Locality heuristics DefragmentationBlock groups, Reserve space Best fit, Defragmentation Write anywhere, Block groups See book for details

15. spcl.inf.ethz.ch @spcl_eth FAT file system 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 17 16 18 19 file 9 block 3 file 9 block 0 file 9 block 1 file 9 block 2 file 12 block 0 file 12 block 1 file 9 block 4 FATData blocks Free space: Linear search through FAT

16. spcl.inf.ethz.ch @spcl_eth FAT file system 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 17 16 18 19 file 9 block 3 file 9 block 0 file 9 block 1 file 9 block 2 file 12 block 0 file 12 block 1 file 9 block 4 FATData blocks Slow random access: need to traverse linked list for file block

17. spcl.inf.ethz.ch @spcl_eth FAT file system 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 17 16 18 19 file 9 block 3 file 9 block 0 file 9 block 1 file 9 block 2 file 12 block 0 file 12 block 1 file 9 block 4 FATData blocks Very little support for reliability: lose the FAT and it’s game over

18. spcl.inf.ethz.ch @spcl_eth FAT file system 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 17 16 18 19 file 9 block 3 file 9 block 0 file 9 block 1 file 9 block 2 file 12 block 0 file 12 block 1 file 9 block 4 FATData blocks Poor locality: files can end up fragmented on disk

19. spcl.inf.ethz.ch @spcl_eth FFS

20. spcl.inf.ethz.ch @spcl_eth Inode array Metadata Data block FFS uses indexed allocation Inode Block pointers File inode number from directory entry File is represented by an index block or inode File metadata List of blocks for each part of file Directory contains pointers to inodes

21. spcl.inf.ethz.ch @spcl_eth Unix file system inode format (simplified) File mode Owner/group Timestamps Size 12 direct block pointers Single indirect Double indirect Triple indirect Data block indirect block Data block … … … … … … indirect block Inode: (all blocks 4kB)

22. spcl.inf.ethz.ch @spcl_eth NTFS

23. spcl.inf.ethz.ch @spcl_eth NTFS Master file table MFT Std. info Attributes, data, metadata free MFT record: Lots of options for what goes in here 1 kB fixed size

24. spcl.inf.ethz.ch @spcl_eth NTFS small files  Small file fits into MFT record: Std. info File data free Filename “resident” data

25. spcl.inf.ethz.ch @spcl_eth NTFS small files  Small file fits into MFT record:  Hard links (multiple names) stored in MFT: Std. info File data free Filename Std. info File data free Filename1 Filename2 “resident” data

26. spcl.inf.ethz.ch @spcl_eth NTFS normal files  MFT holds list of extents: Std. info Start, length free Filename Start, length Data (extent 0) Data (extent 1) Data (extent 2)

27. spcl.inf.ethz.ch @spcl_eth Too many attributes?  Attribute list holds list of attribute locations Std. info Attr. list Filename 2 Filename 1 name data Std. info Start, length free Start, length MFT entry 2 nd MFT entry In addition, attributes can also be stored in extents  very large scaling (see book)

28. spcl.inf.ethz.ch @spcl_eth Metadata files  File system metadata in NTFS is held in files! File num.NameDescription 0$MFTMaster file table 1$MFTirrCopy of first 4 MFT entries 2$LogfileTransaction log of FS changes 3$VolumeVolume information & metadata 4$AttrDefTable mapping numeric IDs to attributes 5.Root directory 6$BitmapFree space bitmap 7$BootVolume boot record 8$BadClusBad cluster map 9$SecureAccess control list database 10$UpCaseFilename mappings to DOS 11$ExtendExtra file system attributes (e.g. quota)

29. spcl.inf.ethz.ch @spcl_eth 29 opendir(3) - Linux man page Name opendir, fdopendir - open a directory Synopsis #include DIR *opendir(const char *name); DIR *fdopendir(int fd); Description The opendir() function opens a directory stream corresponding to the directory name, and returns a pointer to the directory stream. The stream is positioned at the first entry in the directory. The fdopendir() function is like opendir(), but returns a directory stream for the directory referred to by the open file descriptor fd. After a successful call to fdopendir(), fd is used internally by the implementation, and should not otherwise be used by the application. Return Value The opendir() and fdopendir() functions return a pointer to the directory stream. On error, NULL is returned, and errno is set appropriately.

30. spcl.inf.ethz.ch @spcl_eth 30 readdir(3) - Linux man page Name readdir - read a directory Synopsis #include struct dirent *readdir(DIR *dirp); Description The readdir() function returns a pointer to a dirent structure representing the next directory entry in the directory stream pointed to by dirp. It returns NULL on reaching the end of the directory stream or if an error occurred. On Linux, the dirent structure is defined as follows: struct dirent { ino_t d_ino; /* inode number */ off_t d_off; /* offset to the next dirent */ unsigned short d_reclen; /* length of this record */ unsigned char d_type; /* type of file; not supported by all file system types */ char d_name[256]; /* filename */ }; Return Value On success, readdir() returns a pointer to a dirent structure. (This structure may be statically allocated; do not attempt to free(3) it.) If the end of the directory stream is reached, NULL is returned and errno is not changed. If an error occurs, NULL is returned and errno is set appropriately.