30 File – System Interface – III

Mary Anitha Rajam

33.1 Introduction

The file system is the most visible part of an operating system. File systems are kept in secondary storage devices. File systems can be kept in different partitions, different disks, pen drives and so on. In this module we will learn how a file system can be mounted on another file system, how sharing of files is supported in file systems and how files can be protected.

33.2 File-System Mounting

Similar to how a file must be opened before use, a file system must be mounted before it can be accessed. A single file system can be built out of multiple partitions or there can be a separate file-system in each partition. To logically attach different file systems together and to view the files of different file systems, mounting is done.

The mount procedure is as follows: There is a mount command/system call which is used for mounting. The system is provided with the name of device containing the file system to be mounted and the mount point as arguments to the mount call. The mount point is the directory at which the mounted file system will be attached.

Fig. 33.1 (a) Existing file system. (b) Unmounted file system

Figure 33.1 (a) shows an existing file system with a root directory (/ denotes the root), another directory called users beneath the root directory and so on. Figure 33.1 (b) shows another file system which is to be mounted on the existing file system. The unmounted file system exists on a different device or partition (say, /device/dsk) than the existing file system. Currently, only the existing file system can be accessed. To access the unmounted file system, the unmounted volume has to be mounted (logically attached) on to the existing file system. The mount point, here, is the directory users. During mounting, the root directory of the file system shown in Figure 33.1(b) is logically attached to the directory users in the file system shown in Figure 33.1(a). For mount to succeed, the mounted device should have a valid file system. A table called mount table is kept by the operating system which maintains information about the mount point and the mounted file system. The mount point may or may not be empty. If the mount point is not empty before the mounting, the subdirectories of the mount point may be hidden after the mounting.

Figure 33.2 shows how the existing file-system will look logically after the mounting. The directory jane can now be accessed as /users/jane. The subdirectories of the directory users (bill, fred) are now hidden after the mounting.

33.3  File Sharing

Fig. 33.2 After mounting

Sharing of files is desirable when users want to collaborate and want to achieve a computing goal. Therefore, operating systems must provide support to share files, in spite of the difficulties. In this section, we will discuss different issues that may arise when files are shared.

33.3.1  File Sharing – Multiple Users

In a single user system, the need for the sharing of files may not arise. But, in a multiuser system, more protection and access control are needed for file sharing. Therefore, the system must maintain more file and directory attributes than are needed in a single-user operating system. Most systems use the concepts of owner (user) and group. The owner is responsible for changing attributes and granting access and has the most control over the file. A group defines the subset of users who can share access to the file. For example, in UNIX, the owner of a file can issue all operations on a file like reading, writing and executing. A group can have permissions to issue a subset of operations and all others (other users) can have different access permissions. The owner and group are assigned IDs and the owner and group IDs are stored along with the other attributes of the file. Even with multiple local file systems, ID checking and permission matching are straightforward, once the file systems are mounted. But, what happens when the file systems are not local, but placed in different locations connected through a network? We see the issues related to this in the next section.

33.3.2  File Sharing – Remote File Systems 

With the advent of computer networks, communication among remote computers became possible. Networking allows the sharing of resources spread across the world. Data in the form of files is one such resource.

Files can be shared using the following methods: In the first method, the files are transferred manually via programs like FTP. In the second method, a distributed file system is used, in which remote directories are visible from a local machine In the third method, the World Wide Web is used. A browser is used to gain access to the remote files. The World Wide Web uses anonymous file exchange.

The client-server model allows clients to mount remote file systems from servers. A server can serve multiple clients and a client can use multiple servers. The NFS is a standard UNIX client-server file sharing protocol. The Common Internet File System (CIFS) is standard Windows protocol.

33.3.3  File Sharing – Failure Modes

Information, disk-controller failure or cable failure. Errors caused by users or system-administrators also can cause files to be lost or directories to be deleted.If the file systems are local, the local file systems can fail due to failure of the disk containing the file system, corruption of the directory structure or other disk management

Remote file systems introduce the possibility of new failure modes, due to network failure or server failure. Interruption of networks between the two hosts can be due to hardware failure (failure of switches and routers), poor hardware configuration or network implementation issues.

Let a client be in the midst of using a remote file system. It may be opening files, reading from or writing to files, closing files etc. Now, if the server crashes or shuts down, the files are no more accessible. The client system should now terminate all its operations or wait until the server is reachable again. Terminating all operations may result in losing data. Therefore, most protocols allow delaying of operations so that the remote host will become available again.

To implement this type of recovery from failure, some state information has to be maintained in the server and the client. If both the client and the server maintain information about their current activities and their open files, it becomes easy to recover from a failure. NFS implements a stateless distributed file system. In NFS, all information is included in each request, allowing easy recovery. But security is less because forged read or write requests are allowed by the NFS server.

33.3.4  File Sharing – Consistency Semantics

Consistency semantics specify how multiple users are to access a shared file simultaneously

•  Specifies when modification of data by one user will be seen by other users

•  A file session is a series of file accesses between an open() and close() operations

•  Andrew File System (AFS) has session semantics

•  Writes to an open file by a user are not visible immediately to other users that have the same file open

•  Once a file is closed, the changes made to it are visible only in sessions starting later

•  Already open instances do not reflect these changes

•  Writes only visible to sessions starting after the file is closed

•  Unix semantics:

•  Writes to an open file visible immediately to other users who have this file open

•  File has a single image that interleaves all operations, regardless of their origin

•  Immutable-Shared-Files semantics:

•  Once a file is declared as shared by its creator, it cannot be modified

•  The contents of an immutable file cannot be altered

•  The files are read-only

33.4 File Protection

It is necessary to keep files safe from physical damage (reliability) and from improper access (protection). For keeping the files reliable, it is necessary to have duplicate copies of files. We can also periodically copy disk files to tape at regular intervals.

We now see how files can be protected from improper access. The owner/creator of the file should be able to control what can be done on a file and by whom. The types of access that can be controlled are read, write, execute, append, delete, list, renaming, copying etc.

One way in which access can be controlled is to have access control lists and groups.

33.4.1  Access Control Lists and Groups

With each file and directory an access-control list (ACL) is attached. The ACL has the names of users and the types of access allowed for each user. When a user requests access to a particular file, the access list is checked. If the user is listed for that particular access, access is allowed. Else, user is denied access.

The problem with ACL is the length of the list. When the number of users becomes very large, the list becomes very long. This list has to be maintained for each and every file as well. It is needed to know in advance the list of users in the system. The directory entry must be of variable size (cannot be fixed). Each file in the directory can have a different access control list and the size of the list may vary.

To overcome this problem a condensed access-control list is used. In this access control list, the users are divided into categories – owner, group and universe.

In some operating systems like the Solaris, a combination of both the above-mentioned types of ACLs is used. In Solaris, by default, the three categories of access (owner, group and universe) are allowed. For specific files and directories, more fine-grained access control is allowed (by having an ACL listing all the users who can access with their type of access).

In UNIX, directory and file protection are handled similarly. Each file has three fields – owner, group and others. For each field there are three bits, r, w and x, corresponding to read, write and execute permissions. Suppose, the owner is provided read, write and execute permissions, r, w and x are set to 1 respectively. The octal number corresponding to the permissions allowed is 7 (111 in binary). Suppose the group is provided permissions for read and write, but no permissions for execution, the octal number for permissions is 6 (110 in binary). If others (universe, public) are provided only execute permissions, the octal number for permissions is 1 (001 in binary).

r w x

a) owner access	7	⇒	1 1 1
b) group access	6	⇒	1 1 0
c) public access	1	⇒	0 0 1

Thus, the access word for the file is 761 (rwx). Figure 33.3 shows a sample UNIX directory listing. The first file in the list is intro.ps. This file has read and write permissions for owner, read and write permissions for group and read permissions for others. The second row corresponds to a subdirectory called private in the listed directory. The letter ‘d’ before the access permissions indicates that ‘private’ is a directory. This directory ‘private’ has read, write and execute permissions for owner, but no permissions for group and others. For the next directory ‘doc’, there are read, write and execute permissions for owner; read, write and execute permissions  for  group;  read  and  execute  permissions  for  others.  In  a  directory, execute permissions is having permissions to search the directory.

Fig.33.3 A sample UNIX directory listing (Source: [1])

Figure 33.4 shows a example of access control provided for guest user in Windows XP. The guest user is denied all permissions.

Fig.33.4 Windows XP Access-control List Management

33.4.2  Other Protection Approaches

There are also other ways to protect files. The most commonly used is to associate a password with each file. Passwords must be chosen randomly and changed often. But the disadvantage is that the user may have to remember a number of passwords. If the user uses only one password for all the files, once the password is discovered, all files become accessible. Some systems allow users to associate password with a subdirectory. In this case, it is not necessary to assign a password for each and every file within this directory. It is enough to assign a single password for the entire directory.

33.5 Summary

In this module, we learnt what is meant by mounting of file-systems. We also learnt the issues in file sharing. We learnt what is meant by consistency semantics and the approaches used in different operating systems. We also learnt how files can be protected.

References

1. Abraham Silberschatz, Peter Galvin, Greg Gagne, “Operating System Concepts”, Ninth Edition, John Wiley & Sons Inc., 2012.
2. Andrew S. Tanenbaum, Herbert Bos, “Modern Operating Systems”, Fourth Edition, Pearson Education, 2014.
3. Gary Nutt, “Operating Systems”, Third Edition, Pearson Education, 2009.