In the previous article we saw how the hidden directory entries named
. (dot) and
(dot dot) tie the filesystem together. Those names are hard links that
reference the actual filesystem object through the index number. A
directory always has at least two names:
. and its given name. You can always reach the parent directory through the
Now let’s dig into how pathnames and permissions work internally. (If you’re familiar with all of this, try the quiz at the end.)
Pathnames can confuse users, but they’re actually simple when you see how they work. A pathname gives the location of an object (a file, a directory, a socket, etc.) in the filesystem. There are two kinds of pathname: absolute (or full) and relative:
/home/jpeek, two relative pathnames you might type are:
No matter what your current directory is, you can always find an object through its absolute pathname. But a relative pathname is often shorter.
When you give a pathname to a program, how does it find the object you specified? For an absolute pathname, it reads the root directory and follows the path from there. Otherwise, the program opens the current directory and follows the path from there.
Figure 1 shows how the shell’s system calls find a directory after you type
cd /home/jpeek. This figure comes from part of the filesystem tree in the previous article.
/, so the system opens the root directory.
/homedirectory, it looks for a directory entry named jpeek.
Here are some more examples: multiple ways to reach the same directory. I’ll start by changing the current directory to my home directory. (A simple cd with no pathname defaults to a user’s home directory.)
1$ cd 2$ ls -ai 5423 . 58 .. 5425 bin 5424 foo 3$ ls -ai . 5423 . 58 .. 5425 bin 5424 foo 4$ ls -ai ././. 5423 . 58 .. 5425 bin 5424 foo 5$ ls -ai ../jpeek 5423 . 58 .. 5425 bin 5424 foo 6$ ls -ai /home/jpeek 5423 . 58 .. 5425 bin 5424 foo 7$ ls -ai /home/jpeek/. 5423 . 58 .. 5425 bin 5424 foo 8$ ls -ai /home/jpeek/../jpeek 5423 . 58 .. 5425 bin 5424 foo 9$ ls -ai /jpeek ls: cannot access /jpeek: No such file or directory
Every ls command lists the same directory, some through relative pathnames and some through absolute. Command 4 opens
., then opens
., then opens
. again: always the same directory. Command 8 opens
/home/jpeek, then the parent directory, then the jpeek directory from there — with the same result.
Why did command 9 fail? Trace it through: open the root directory, then look for an entry named jpeek. There isn’t one.
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:
*. (Some graphical filesystem browsers will say a directory is “unreadable” unless it also has execute permission, but that’s not strictly true.)
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 root 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
Permission deniedbecause there’s no read permission on
/home, the parent of
ls: cannot open directory .because there’s no read permission.
vim .profileto modify Zoe’s startup file. What happens?
cd /home/zoe, then
rm afile. What happens?
.because he has read permission. He removes afile because he has write permission on
.(the directory containing the entry for afile).
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!
Jerry Peek is a freelance writer and instructor who has used Unix and Linux for more than 25 years. He's happy to hear from readers; see http://www.jpeek.com/contact.html.
[Read previous article]
[Read next article]
[Read Jerry’s other Linux Magazine articles]