| Elan Sleazebaggano: | You wanna buy some death sticks? |
| Obi-Wan: | You don't want to sell me death sticks. |
| Elan Sleazebaggano: | I don't want to sell you death sticks. |
| Obi-Wan: | You want to go home and rethink your life. |
| Elan Sleazebaggano: | I want to go home and rethink my life. |
| -- Attack of the Clones | |
Things to consider when working with file systems:
We went over a lot of the file system things pretty quickly. I got the sense that many people had seen a lot of this before. So we move on.
To this point, we have talked about "partitions" as subdivisions of an individual disk. It is also possible to have a logical "partition" span multiple disks.
RAID - Redundant Array of Independent/Inexpensive Disks
The bullpen cluster includes a RAID:
12 disks, 18 GB each. Connected to one Wide-SCSI controller. The system sees it as one big partition:
> df -k /export/raid Filesystem kbytes used avail capacity Mounted on /dev/dsk/c1t5d0s6 191175687 25709437 163554494 14% /export/raid
There are many ways to organize a RAID (Tanenbaum, Figure 5-19):
Where does this happen?
Recall our memory hierarchy:
Just as virtual memory uses disks to simulate a larger main memory, tapes and other removeable media can be used to simulate a larger disk.
These systems are found at large supercomputing centers.
Other issues:
The operating system is (in part) responsible for protection - to ensure that each object (hardware or software) is accessed correctly and only by those processes that are allowed to access it.
We have seen protection in a few contexts:
We want to protect against both malicious and unintentional problems.
Protection Domains
There are a number of ways that an OS might organize the access rights for its protection system. A domain is a set of access rights and the objects (devices, files, etc.) they refer to.
An abstract example from Tanenbaum:
This just means that processes executing in, for example, domain 1, can read file1 and can read and write file2.
The standard Unix protection system can be viewed this way. A process' domain is defined by its user id (UID) and group id (GID).
Files (and devices, as devices in Unix are typically accessed through special files) have permissions for: user, group, and other. Each can have read, write, and/or execute permission.
A process begins with the UID and GID of the process that created it, but can set its UID and GID during execution. Whether a process is allowed a certain type of access to a certain file is determined by the UID and GID of the process, and the file ownership and permissions.
The superuser (UID=0) has the ability to set processes to any UID/GID. Regular users usually rely on setuid and setgid programs in the filesystem to change UID/GID.
An executable file with the setuid (setgid) bit set will execute with the effective UID (GID) of the file's ownership rather than the process that runs it.
Example: see /usr/X11R6/bin/xterm on your favorite Unix system. Yes, each time you start an xterm, you're the superuser (!), at least for a few moments.
Other possible protection mechanisms:
See Tanenbaum for details on these.
In any case, the OS must enforce the protection mechanism as appropriate.