1. Chapter 10.3: File-System Interface

2. 10.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 10: File-System Interface Chapter 10.1 File Concept Access Methods Chapter 10.2  Directory Structure – continued  More on links – Unix.  File-System Mounting  Protection

3. 10.3 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts More on Links

4. 10.4 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts More on Links…from Sobell book Links – allows a file to be accessed by two or more names. The alternative name can be located in the same directory as the original file or in another directory. Links may be used to make the same file appear in several users’ directories thus enabling them to share the file easily. The additional links appears as another file in the file structure. If the file appears in the same directory as the one the file is linked with, the links must have different filenames. (example ahead) But this restriction does not apply if the linked file is in another directory.

5. 10.5 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Links – in Practice The following command builds the link (see next figure). The command assumes that /home/jenny is the working directory and that Jenny is creating a link to the file named draft. The new link appears in the /home/alex directory with the filename letter. (In practice, it may be necessary to use a chmod to give Jenny write access permission to /home/alex/letter of course.) Statement: ln draft /home/alex/letter

6. 10.6 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Link Figure /home/alex/letter and /home/jenny/draft home alex jenny Memo planning

7. 10.7 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Links – in Practice The ln utility creates an additional pointer to an existing file. It does NOT make another copy of the file. Thus the file status information (access permissions, owner, …) is the same for all links. Only the file names differ. You can verify that ln does not make an additional copy of the file by creating a file, using ln to make an additional link to the file, changing the contents of the file via one link (use vi or pico), and verifying the change through the other link.

8. 10.8 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Here’s some code: $ cat file_a This is file a $ ln file_a file_b // same directory here… $ cat file_b This is file_a vifile_b … change contents in file_b $ cat file_b This is file_b after the change $ cat file_a This is file _b after the change.

9. 10.9 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Still More on Links – kinds of links A link is simply a pointer to a file. Two kinds: hard links and symbolic links. A hard link associates a file name with a place on the disk where the contents of the file are located. A symbolic link associates a file name with the pathname of a hard link to a file. Much more power here. See ahead.

10. 10.10 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Hard Link A hard link is a directory entry that contains the file name and inode number for the file, which merely identifies the location of the control information for the file on disk, which in turn identifies the location of the file’s contents on the disk. Every file has at least one hard link, which locates the file in a directory. When you remove the last hard link to a file, you can no longer access the file. Hard links are our accustomed links.

11. 10.11 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Symbolic Link A symbolic link is also a directory entry but it points to the pathname of another file. In most cases, a symbolic link to a file can be used in the same ways a hard link can be used. But: unlike a hard link, a symbolic link can span file systems and can connect to a directory. Background: Because each file system has a separate set of inodes, you can normally create hard links to a file only from within the file system in which the file resides. To get around this, Unix has these symbolic links which do not share inode information, and you can thus create such a link to a file from within any file system.

12. 10.12 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Recall: Inodes You should know that an inode is simply a data structure that contains information about a file: file length, times the file was last accessed, owner and group IDs, access privileges, number of links, and pointers to the data blocks that contain the file itself. Each directory entry associates a filename with an inode. Although a single file may have several filenames (one for each link), it has only one inode in the same directory. (As stated, symbolic links provide us with additional flexibility if needed.)

13. 10.13 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts File System Mounting

14. 10.14 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts File System Mounting A file system must be mounted before it can be accessed and a directory structure may involve a number of volumes. When we say ‘mounting a file system’ we are to mount a file system is to make it accessible to system users. When a file system is not mounted, one cannot read from or write to files it contains. Mounting refers to tying your directories (w/volumes if need be) into the file-system name space. (making them ‘active’) We look at ‘mounting’ your file system into the overall file structure so that processes may access your file system. On Unix, a file system might contain a user’s home directories and would be mounted as /home. Within /home, then, within this file system, we would create more directory names with /home as in /home/jane. Mounting such a file system under /users would result in a path name: /users/jane.

15. 10.15 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Definition of Mount – Unix But, before we proceed: note the definition of Mount (Google) The mount Unix command line utility instructs the operating system a file system is ready to use, and associates it with a particular point in the system's file system hierarchy (its mount point).Unixutility operating systemfile system The counterpart umount (note spelling) instructs the operating system that the file system should be disassociated from its mount point, making it no longer accessible. The mount and umount commands require root user privilege or the corresponding fine-grained privilege.root user

16. 10.16 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Many variations on mounting restrictions… Some systems may not allow you to mount your file system over directories that contain files. (examples ahead) While the mount may be available, it may cover up files already present at the mount point. If/when this file system is un-mounted, then the original files become available again. Some systems allow the same file system to be mounted in more than one place – or just one place. Consider the example on the next slide to see how some of these peculiarities may occur:

17. 10.17 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts (a) Existing. (b) Unmounted Partition Can see the existing system and existing sub-trees of directories and files. Note we have this an unmounted file system in ‘b’. When we mount this file system under /users, we get the visual on the next graph.

18. 10.18 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Mount Point You may readily observe that the unmounted file system is (second figure above) is now mounted under /users/ (first figure above) But note: (in the second figure) – what happened to bill, fred and everything beneath it? In this approach, that file system is not available until this new file system is dismounted. There are some issues concerning file system mountings – covered in next Chapter. After mount Before the mount

19. 10.19 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts A bit more on Mounting - Examples Mount attaches a file system to the file system hierarchy at a specified mount_point, which is the pathname of a directory. If mount_point has any contents prior to the mount operation, these are hidden until the file system is unmounted. (hence Bill, Fred, etc. in previous slide) The umount utility unmounts a currently mounted file system, Enough for now.

20. 10.20 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Protection and Access Control

21. 10.21 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Protection This is all about protecting our resources… Here we talk about ‘reliability.’ All reputable computing systems operations perform backups with strict regularity –  Periodic maintenance; ‘system saves’ done usually during early morning hours, etc. discuss.  Files get lost, corrupted, damaged by hardware, and more… We talk about ‘protection.’ File owner/creator should be able to control: what can be done, who can access the data, with what kinds of access, and more. In multi-users systems, this is critical! Note also that there is a full chapter devoted to protection ahead in this course.

22. 10.22 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Protection We normally control access by restricting types of access to certain people, groups, not protect at all, or something in between. Typical types of access Read – reading a file Write – writing to or rewriting a file Execute – loading the file and executing it. Append – adding additional information to the end of a file Delete – deleting a file and de-allocating its space List – listing the name and various attributes of the file such as  Size, permissions, date created, etc. More: renaming, coping, etc. Different types of protection are needed depending on location/ criticality/ sensitivity/ security, etc. of the system.

23. 10.23 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Access Control Bottom line: want to be able to identify users – or at least group of users. Common approach: associate an access-control list with each file / directory. Specifies user names and types of access allowed. Upon attempted access, the user is verified against this access list: Granted access or Denied access and a protection violation occurs. But lists, by themselves, can be long and require constant updating.. Maintaining such a list associated with a directory complicates space management if the size of the access list grows and more space must be allocated. Searching such a list can be problematic too. We need a more practical approach.

24. 10.24 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Access Control - more Many systems categorize users into groups: Owner – user who creates the file; owns the file Group – a group of users who can access the file and need some specific access – specific permissions to be listed for group. Universal access (or World) Still, systems use categories above for general use but some also provide for an access control list for certain files / directories as an additional layer of access control. It is not rocket science to fabricate a case where an owner has ‘all permissions’ but where groups of workers need access to certain files / directories to do their work on a project and where still others might only need to be able to read what is going on… If additional types or special constrained access is desired, then access control lists may accompany standard categories of owner, group, and world. (example ahead)

25. 10.25 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Access Control – still more If the category approach is sufficient, as it oftentimes is, the typical implementation of this is to have three fields each of which are three bits, where the bits: rwx, represent access to read, write, and execute permissions for a specific file, directory, etc. Three three-bit fields are used: one for owner, one for group, and one for the world. (total: nine bits) As a sample, I am providing a small snapshot of one of my personal directories: (next slide) Can see the ‘d’ means directory. All other entries are files Can see size in blocks, my ‘n’ number – used in my environment for positive identification - a text field citing that I am faculty, block size for the individual entry in the file system, date the entry was created, and the item name (file or directory).

26. 10.26 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts An Expansion of a Directory Showing Permissions ! osprey.unfcsd.unf.edu $ ls -l total 10708 drwxr-xr-x 2 n00010109 faculty 4096 Apr 21 2006 ai -rwxr-xr-x 1 n00010109 faculty 14490 May 31 2005 a.out drwxr-xr-x 2 n00010109 faculty 4096 Apr 21 2006 c drwxr-xr-x 7 n00010109 faculty 4096 Apr 21 2006 c++ -rw-r--r-- 1 n00010109 faculty 1241 Jan 18 1997 chen.tmp drwx------ 7 n00010109 faculty 4096 Apr 21 2006 cis4251 drwx------ 9 n00010109 faculty 4096 Apr 21 2006 cis6930 drwx------ 20 n00010109 faculty 4096 Apr 21 2006 cop2220 Note the first entry is a directory named ‘ai, ’ two blocks, created in 2006 and block size is 4K. As owner, I have all permissions; others may read and execute but may not write. Note the file chen.tmp (happens to be a letter of recommendation) I can read it and write to it, others may read only. (it is not an executable file) Then three directories are listed one each for three courses I have taught at the dawn of civilization!

27. 10.27 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts More on the Directory 1. Below, I printed my location (working directory) in my file system (pwd) after I had changed directories (went down the tree) to a directory names ‘c’ 2. I then listed its contents (only part is shown). 3. But, since I ‘own’ this directory, I changed permissions for the file array1.c. via a chmod command to 744, which is 111 100 100 bits for rwxr—r--. respectively. 4. I then listed its contents again to show changed permissions. ! osprey.unfcsd.unf.edu $ pwd 1 /home/09/n00010109/c ! osprey.unfcsd.unf.edu $ ls –l 2 total 60 -rw-r--r-- 1 n00010109 faculty 661 Nov 17 1997 array1.c 3 ! osprey.unfcsd.unf.edu $ chmod 744 array1.c Here I changed access permissions ! osprey.unfcsd.unf.edu $ ls –l and then listed the contents again. total 60 4 -rwxr--r-- 1 n00010109 faculty 661 Nov 17 1997 array1.c Note permissions change! -rw-r--r-- 1 n00010109 faculty 3592 Nov 20 1997 ass6.c

28. 10.28 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Access Control List – example There’s an example in your book (p. 405) that indicates the presence of an access control list: 19 -rw-r—r--+ jim staff 130 May 25 22:13 file1 This example is a Solaris example that indicates there are optional ACL permissions set on the file, file1. The access list is indicated by the presence of the ‘+.’ In Solaris, special commands setfac1 and getfac1 are used to manage the access control lists, if any.

29. 10.29 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Other Protection Mechanisms Sometimes we only use a simple password approach for each file. This can work, but as in the case of any passwords, one can forget the passwords, and, if passwords are used for multiple items, access control may not restrict access to the extent intended.

30. 10.30 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Lastly Need to protect files & collections of files in directories and subdirectories. Directory commands must be (should be) different than commands for files rmdir versus rm mkdir – specifically creates a directory from your current directory where command issued. Sometimes need to conceal the presence of a file/subdirectory in another directory. So listing the contents of a directory (ls) may need to be prevented. But with certain directory / file system organizations this can be very complicated. If a path name refers to a file in a directory, the user must be allowed access to both the directory and the file. But in systems where files may have various path names, as in acyclic or general graphs, a user may have different access rights to a particular path depending on the path name used!

31. End of Chapter 10.3