▶ 3.1 The File System
Data sharing poses a problem: If people can look at some information on a computer, how do we prevent them from seeing all the information? This is the same problem as RAM protection. If any user can read any information inside the computer, we can’t prevent users from reaching any of its contents.
For most people, important information assets reside in files. Modern file systems keep the hard drive organized so we may reliably locate and save our data.
All modern systems use a hierarchical directory to organize files into groups. The directory forms an inverted tree growing from the topmost directory, called the root directory. Many users think of files as living in file folders instead of directories. In practice, we use the terms interchangeably.
On Microsoft Windows, each drive has its own directory, starting at its own root. FIGURE 3.1 shows the root folder for a Windows system drive. We can tell it’s the root because the “Address” field of the window only contains the drive letter (“C:”) and no other names.
FIGURE 3.1 Root directory folder on Windows drive C:.
Used with permission from Microsoft.
On Unix-based systems, the system drive provides the root. The directories on all other drives appear beneath it in the hierarchy. In MacOS, there is a Volumes subdirectory that leads to the directories for individual drives.
When we click on a folder icon within a folder on our desktop, we go “down” a level in the directory hierarchy (FIGURE 3.2). On Windows, the “Address” field contains the directory’s name following the “” character.
FIGURE 3.2 The “downloads” subdirectory.
Used with permission from Microsoft.
Directory Path and File Names
Each file on a hard drive has a unique identifier made of the file’s name and the list of directories leading to it. If a file is in the root directory, then we don’t need a directory name to find it. All we need is the “” character, which by itself indicates the root directory. In Figure 3.1, we see a file named “hello.txt” in the root directory. The file’s entire name consists of the drive letter, a “” character, and the file name:
If the file is in a subdirectory, then we need both the name and the directory path, which leads us to the file’s directory starting from the root directory. We see from Figure 3.2 that there is also a file named “hello.txt” in the “downloads” directory. To choose this file, instead of the one in the root directory, we include the path to its directory:
If the file resides in a directory within the “downloads” directory, then we must include that directory in the path. Each directory name is separated by a “” and they occur in order starting from the root directory. Not all systems use the same character to separate directory names; TABLE 3.1 lists the commonly used characters.
TABLE 3.1 File and Directory Name Formats |
|---|
|
File systems, like operating systems, mostly fall into either of two categories: Windows systems and Unix-based systems. Apple’s MacOS is based on a version of Unix, but it uses a distinctive file system. Unless otherwise noted, like in Table 3.1, MacOS has the features of a Unix-based system.
3.1.1 File Ownership and Access Rights
Bob has started a small bookkeeping business next door to Alice. Bob has bought a new “tower” computer and has agreed to share it with Alice. He has activated the login mechanism and constructed three logins: one for an administrator (“superbob”), one for his bookkeeping business (“bob”), and one for Alice (“alice”). He established passwords for all three accounts. Bob saves his clients’ information on the hard drive. Most clients are local businesses. A few clients compete with Alice. How does Bob keep Alice from looking at competitors’ business information?
Bob thinks Alice is reasonably trustworthy, but he has an obligation to his clients to keep their information secret. He needs to protect his files from Alice, whether she looks at them accidentally or on purpose. Some desktop operating systems allow us to run without the apparent need for user identities or file protection, but all modern systems provide those features.
Modern operating systems protect files according to user identity. When Bob logs in as “bob” and presents his secret password, the system starts up a graphical interface process. This process lets Bob run programs and use his files (FIGURE 3.3).
FIGURE 3.3 Bob’s processes inherit his identity and access rights.
The system associates Bob’s user identity with the processes he runs. When he edits a client’s spreadsheet, the spreadsheet program takes on his user identity. It then creates and modifies his files on his behalf. Bob created the spreadsheet files so the system naturally grants him access rights to the files.
File Access Rights
When we looked at RAM access in Chapter 2, we focused on “read” and “write” access permissions. An operating system provides four access rights for files and most other resources:
■ Create a new instance of the resource (e.g., a new file).
■ Read the contents of a particular resource.
■ Update or “write” or “modify” a particular resource.
■ Delete or destroy an existing resource.
The names of these four rights form the acronym CRUD. While the four rights also may apply to RAM and processes, it’s most common for programs to apply them to files. When a process tries to create or use a file, it inherits whatever rights belong to the user who started the process.
Some systems also provide a right to append to a file; that is, add data to the end of the file without reading its contents. There also may be an execute right that we will examine later.
Initial File Protection
A modern personal computer may easily contain hundreds of thousands of files. This multitude poses a real problem: How do we establish protections for all of them? It’s not practical to set permissions individually. The system has to apply the correct permissions automatically whenever a user creates a new file or directory. Systems tend to implement either of two mechanisms to apply initial access rights:
Default rights: the system applies a standard set of permissions to all files a particular user creates. This is common in Unix-based systems.
Inherited rights: the system applies permissions inherited from one or more enclosing directories. We will see specific examples of this in our discussion of sharing files in Chapter 4.
3.1.2 Directory Access Rights
Directories (folders) tie together files in different parts of the hard drive. A file exists because it has a directory entry, and we must change that directory entry to delete it. Thus, we don’t have full control over a file unless we have the right to change its directory entry.
FIGURE 3.4 shows the directory structure in which Bob’s essay file resides. The file resides in Bob’s personal directory (named bob). His personal directory resides in the system’s “root” directory. To find the file, Bob’s process starts at the root directory and looks for Bob’s personal directory. The root directory entry leads the process to Bob’s personal directory, and then the process searches Bob’s personal directory. The entry in that directory leads it, finally, to the file itself.
FIGURE 3.4 Directory and file ownership.
Operating systems grant or deny rights in terms of containers. We may have the right to change the file itself; we may even own the file, but we need rights to its directory in order to change that directory entry.
The basic access rights to a directory are read and write. Bob has the right to read his own directory, so he can list the files in his directory and look at file details stored in that directory. Bob also can write to his own directory, so he can add, modify, or delete files listed in it.
Many systems implement one or more directory-specific access rights. Most systems provide a seek right. This is separate from the read right; it allows the user’s process to search a directory for a particular name in a file’s path, but not to examine the directory as a whole. This permission allows other users to retrieve a file from a directory even if they don’t have the right to read the entire directory.
For example, the system could give Bob the right to seek file names in the root directory but withhold the right to read that directory. Bob would be able to locate his own directory by name. He would not be allowed to list the names of other files or directories in the root.
To protect the directories belonging to other users, Bob does not have the right to write to the root directory. Because of this, Bob does not have the right to delete his own directory.
Some systems provide very specific rights for managing directories, while others provide minimal rights, like read, write, and seek. Here is a detailed listing of possible rights a system could grant for access to a directory:
■ Create a new directory—like the generic creation right.
■ Delete a directory—like the generic deletion right. This operation can be tricky because directories contain files, and the process might not have delete rights for all of its files.
■ Seek a directory for an entry—the right doesn’t necessarily allow the process to list the names of all directory entries, or to examine properties of individual entries.
■ Read a directory—this right allows listing of the directory as well as seeking files in it.
■ Create new files in a directory—may be part of a generic “write” permission or a separate right.
■ Delete files in a directory—part of a generic “write” permission or a separate right.
We can come close to implementing these distinct rights even if the system restricts us to read, write, and seek rights. The arrangement would not be able to distinguish between creating or deleting files or directories.
If the system implements these six distinct rights, it can achieve a higher degree of Least Privilege. This may or may not be important, depending on the security policy we need to enforce. If the policy doesn’t need to distinguish between files and directories, then the extra rights aren’t necessary. In either case, we want the system to apply protections that enforce our policy objectives.