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:

Using "chmod <pattern> <files>". <pattern> is, for example, "u+rw" to add Read and Write to Your permissions on the file. Or "g-x" to subtract eXecute permissions from the file's Group.
Using "chmod <octal number> <files>". Octal is nice for this because the read-write-execute permissions for user,group, or other fit into one octal digit. This is what hardcore UNIX folks use--if they want "rw- r-- ---" permissions, they just say "chmod 640 file.txt".
Using "umask". Your "umask" controls the permissions of files you create. It's the BITWISE COMPLEMENT of the chmod mask. So to create files with permission 755 (you can read write and execute, everybody else can just read and execute newly-created files), you'd say "umask 022", since 0755 = ~0022. I told you bitwise operations would come in handy! Of course, in practice everybody always sets their umask to one of (in order of increasing paranoia):

"umask 002" (disallow write by non-group people, allow everything else)
"umask 022" (disallow write by group or non-group people)
"umask 027" (disallow write by group, and disallow everything by non-group)
"umask 077" (disallow everything for everybody but me)
"umask 777" (trust no one: don't even let me read or write my own files! I might be one of... them!)

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).

Mounting

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:\".

Chroot

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.

What	Read and Write?	Linux	Windows
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!	/dev/dri/card0	\\.\Display1
A process's memory	Reads and writes to memory--useful for a debugger, or learning.	/proc/self/mem	(I don't think this exists)
The console	Read returns stuff you've typed at the blinking cursor. Write prints stuff to the screen.	/dev/tty	CON
Emptiness	Read returns nothing. Write seems to work, but does nothing. This is useful for testing file I/O programs!	/dev/null	\\.\NUL

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).