There’s a Lot in the Dot: Filesystem Permissions and Pathnames (Part 2)
Still deeper into the dot (.) with an dive into access permissions. Study up because there's going to be a quiz.
Once you see how pathnames work, understanding access permissions is simple. You’re probably familar with access permissions for files: read permission lets a program read the file’s contents, write permission allows modification, and execute permission is for executable programs. Notice that none of those permissions control whether you can rename or delete the file. Why? We’ll see soon.
A directory is actually just a special type of file, and a directory’s permissions are easy to understand when you realize that a directory holds entries for other files. So:
- Read permission lets a program read the entries listed in the directory — for instance, with ls or a shell wildcard like
*. (Some graphical filesystem browsers will say a directory is “unreadable” unless it also has execute permission, but that’s not strictly true.)
- Write permssion lets you modify the entries in a directory. Think of the directory as a file in a word processor. To edit the file — to change the spelling or words, add or delete words — you need write permission. A directory is the same way. If you don’t have write permission, you can’t delete, rename, or add entries to the directory. So, to protect the contents of a directory, make the directory unwritable.
- Execute permission lets you access the files linked from a directory. Note that you don’t need read permission; if a directory isn’t readable, you can still access an entry if you know its exact name. (That’s like denying index permission on a web server folder to prevent people from knowing its contents: you can still get a web page by using its exact URI.)
Here’s a directory listing from
ls -l, run by the superuser (who can access everything on the filesystem):
# ls -la /home/zoe
drwxrwx--x 2 zoe users 8192 2010-03-14 18:33 .
drwx--x--x 9 zoe users 16384 2010-03-11 08:00 ..
-rw-r--r-- 1 zoe users 2942 2010-03-16 13:45 afile
drwx------ 2 zoe users 4096 2010-03-14 18:33 dir
-rw-r--r-- 1 zoe users 4039 2009-11-22 08:18 .profile
- Q: An attacker breaks into a non-superuser account that’s not a member of the users group. What does
ls /home show?
Permission denied because there’s no read permission on
/home, the parent of
- Q: The attacker knows that there’s a user named zoe. What does
cd /home/zoe do?
A: It succeeds because the parent directories both have execute permission. But listing would fail with
ls: cannot open directory . because there’s no read permission.
- Q: The attacker tries
vim .profile to modify Zoe’s startup file. What happens?
A: vim opens the file read-only because there’s read permission, but no write permission, on the file.
- Q: jpeek, who’s a member of the users group, types
cd /home/zoe, then
rm afile. What happens?
A: He can access the directory because he has execute permssion. He can list
. because he has read permission. He removes afile because he has write permission on
. (the directory containing the entry for afile).
- Q: What if jpeek now types
A: It fails because he doesn’t have execute permission on dir.
If anything in that quiz surprised you, this might be a good time to open a terminal window and make up some exercises for yourself. Enjoy!