Strange Things You Can Do With Files

CS 321 2007 Lecture, Dr. Lawlor

File Permissions

Who can access a file?  What do you mean by "access"?   Or "who"?

There are cases where reading is OK, but not writing--for example, your grades. 

There are cases where writing is OK, but not reading--for example, a grade "dropbox" directory.

There are cases where you should be able to run a program, but not read, write, or change it (execute only).  Forbidding reads makes it tricker for people to copy or reverse-engineer the program.

There are cases where all you're allowed to do is delete files--for example, to clean out a printer queue.

There are cases where you want to give one person access to a file.  Or a whole group of people.  Or a group of people, but not 3 people in that group.  Or everybody except Bob.

DOS has a shockingly primitive set of file permissions--it's got one read-only bit.  If that bit is set, the file can't be written.  That's it.  DOS has no concept of "users", since hey, you're the user.

UNIX, being a multitasking OS, had a state-of-the art file permission system as of 1970.  It uses 9 whole bits to represent the file permissions--one bit each for read, write, and execute for the file's owner (by user ID), file's group (by group ID), and "everybody".  Suprisingly, this primitive set of permissions is enough to cover most of the cases above; you can see this in "ls -l" format:

 <u>   <- Permissions of the owner of the file
<g> <- Permissions of the group of the file (other than the owner!)
<o> <- Permissions of others (not owner, not group)
<owner> <group> <filename>
-r-------- olawlor family readonly.txt
-rw------- olawlor family readwrite.txt
--w------- olawlor family writeonly.txt
-r--rwx--- fsfoo faculty yourgrades.txt
drwx-wx--- olawlor students dropbox/
---x--x--x olawlor family run_only.exe
-rw-r--r-- bob faculty bob_read_this.txt
----r--r-- bob faculty about_bob.txt
You change permissions in one of three ways:
Windows versions running on NTFS actually have a much nicer, simpler interface: each file has a list of stuff that can and can't happen (an Access Control List, or ACL).


One really beautiful thing you can do on a UNIX machine is "mount" new disks on top of any existing directory.  So if you're running out of room in some deeply-nested directory, you can just mount in a new disk in that very spot.  You do this by saying
    mount /dev/sda2 /home/olawlor/my_giant_mp3_archive
This will mount up my second partition into my home directory.  

Standard UNIX mount hides whatever was in the directory before; a new Linux option (and old Plan9 fix) is to "union" mount, where the new partition's files are visible alongside the old partition's files.

Windows, by contrast, only mounts disks at special "drive letters".  This is annoying, because code wants to live in "C:\Program Files", and you can't make a new disk have that name, it's gotta be "D:\".


Another weird UNIX trick is to "chroot".  This changes the root directory from the point of view of a new program.  So you can, for example, copy an untrusted piece of code into a new empty directory, and run it chrooted to that directory.  The code then can't escape that directory (at least, without becoming root).  NetRun actually uses this to protect the netrun machine from your code!

Device Files

So a file is just a 1D string of bytes, with open, seek, read, write, and close operations.  Suprisingly, there are lots of similar situations all over the place.  Most of these require some special permissions.

Read and Write?
The disk itself. Reading these files reads raw bytes from the disk itself.  Writing to these files changes the disk directly (watch out!).
Disks are a "block device file" like /dev/sda or /dev/fd0 (floppy)
\\.\PhysicalDrive0 or \\.\CdRom0
Input devices (keyboards, mice, joysticks). Reading the file returns what's happening on the device (for example, how the mouse is moving); writing the file can turn on LEDs on the keyboard, or make the joystick rumble. Input devices are in /dev/input (try "od -t x1 /dev/input/event1" and waggle the mouse). USB devices are named strange things like "\\.\HID#Vid_062a&Pid_0102& mi_01&col04#7&bf1aa55&0&0003# {4d1e55b2-f16f-11cf-88cb-001111000030}", but the HID enumerator routines let you list them.
The graphics card
Reading the file can tell you what's being rendered, or what the image is.  Writing the file can cause 3D stuff to start being drawn!
A process's memory
Reads and writes to memory--useful for a debugger, or learning.
(I don't think this exists)
The console
Read returns stuff you've typed at the blinking cursor.  Write prints stuff to the screen.
Read returns nothing.  Write seems to work, but does nothing.  This is useful for testing file I/O programs!

UNIX systems also have a bunch of weird builtin devices like "/dev/zero" (always returns zeros), and "/dev/random" or "/dev/urandom" (returns random numbers, either secure or unsecure).