The Permissive Lifestyle of Linux
All you wanted to know about file permissions
(but felt too powerless to ask!)
If you're a computer user not many years removed from cutting your adult teeth, the concept of “permission” in Unix/Linux operating systems is possibly darkened by the memory of such indignities as having to raise your hand to ask if you may temporarily absent yourself from indoctrination in order to void your bladder in a specialized room.
Chill, dogg! In the Linux Lifestyle, “permission” is all about security, power, and being in the driver's seat. It's part of the bling you get for free with a real OS! It means never having to go “Oops! I think I screwed my system. . .” Well, almost never in the course of ordinary computing. . .if you try hard enough, you can break anything, I suppose. But user permissions allow you to do whatever you want with your stuff without the risk of wrecking the data of other users or the risk of wrecking the operating system!
Everything is a file
In Linux there is a basic concept: functional ownership of files. And in Linux, everything is a file. Some files belong to you as a user, some belong to other users [if your computer has other users] and some belong to the operating system. Before we can adequately understand why permissions are important, we need to understand the different types of files that exist, and how they are used.
Let's get an overview of the different types of files.
The Seven Unix/Linux File Types
Let's explore the seven different classes of files in Linux. Just as ownership in Linux is functional, files are grouped into classes by function. Each class of file has a different symbol when listed, and some have a few alternate names. Below is a table with the symbol, the type of file, it's use, and the alternate name or names for that file type.
— = file: A “plain vanilla” file such as text, image, audio or video data, or an executable program or script. They sometimes [but not always] have a 3 or 4 letter suffix [or extension] that gives a clue as to what the file does, or with what program it is associated.
d = directory: An index to other files. —AKA folder.
l = link: An index pointing to just one other file. —AKA symbolic link, symlink, soft link.
c = character special file: A node for data transmitted one character at a time, a serial stream of data; typically a serial device: keyboard, mouse, USB port, virtual terminal... —AKA character device.
b = block special file: data transmission or storage node for a block of data[a specified number of bits/bytes as a single unit] A block special file is typically a random access device or parallel device like a CD-ROM or HDD. —AKA block device, device node
p = pipe: Pipes connect the output of one Unix process to the input of another. This is fine if both processes are living in the same parent process space, started by the same user. But there are circumstances where the communicating processes must use named pipes. One such circumstance is that the processes have to be executed under different user names and permissions. —AKA named pipe, FIFO
s = socket: A socket is a special file used for inter-process communication. These allow communication between two processes running on the same machine. In addition to sending data, processes can send file descriptors across a Unix domain socket connection using the sendmsg() and recvmsg() system calls. —AKA Unix domain socket [UDS], inter-procedure call socket [IPC socket]
The “Ordinary” File
The ordinary file is familiar. It's a text document, a picture, a multimedia recording: some kind of discrete data object containing information that has been digitized for storage and retreval. That definition is good enough for our purposes for now —with one exception.
A program or a script is also an ordinary file: one that gives the computer instructions to do things. Unlike a file with primarily human-readable content, the program file has primarily machine-readable content. The users are not interested in reading it, but in executing it. So we already see the three main interactions we can have with a file: we can read it, write it or execute it. In Unix/Linux shorthand: “r w x”.
Unix/Linux Directories
“In Linux, everything is a file.” For example: a directory is just a file that is an index to other files.
That is one reason why the Microsoft® habit of calling a directory a “folder” is not helpful for people who really want to understand computer science. Conceptually, the notion of a folder containing a stack of paper sheets is in some ways useful, as an analogy to a digital text or graphic file being listed in a digital directory file. Just like a file cabinet with drawers contains hanging folders, which contain manila folders, which contain typewritten sheets of paper [files] organized by topic, the filesystem directories and subdirectories can be a good way to organize your digital data by topic. But the drawer/folder/file analogy is of limited use.
The directory “contains” data files only in the sense of giving you access to them. Only in the sense that a telephone directory “contains” audio communications with every telephone in your town. It is just as useful, and much more accurate, to think of a “directory” as an index of links.
A directory is a list of hard links that is essential to the filesystem strucure of the partition in which it is located. A file may exist, physically, on the hard disk — but if it is not listed in any current directory, there is no access to it! When you “delete” a file you do not physically destroy the recorded bytes of information. Deleting a file only removes the name of it from it's directory. The only hard link to it in the filesystem is now gone. So when it is gone from the directory, it's gone from the partition —as far as ordinary computer use goes.
But unless that physical spot, now listed by the filesystem as “Vacant: for rent,” has been assigned to another file, the “deleted” file can still be accessed. Special utilities that do not rely on the formatted filesystem's directories, but which can read bytes directly from the disk surface can still recognize the existence of that file. This is called data recovery, and it can get very expensive, as it is very time-consuming, and needs an educated human who knows what s/he is doing to operate the data recovery software.
Your CD-ROM drive and your hard disk drives are block files [AKA “block devices”] that can be attached or “mounted” to your root filesystem. When they are mounted, you can read and write to them like you can any other file.
Wikipedia has a good, not-too-complicated introduction to the concept and implementation of File System Permissions in Unix-based filesystems. Another good explanation of Unix permissions is from the Math Department of Harvey Mudd College, in California.
Both these links go to an external site: in order to keep your place here, you may want to right-click and open in a new window or tab.
A Directory is a Table of Contents. Here's how to read it:
Using the Command Line Interface, or “terminal,” you can obtain a list of all the files in any directory by logging into the directory with the first command, then listing it's contents with the second:
cd /mountpoint/directory
ls -al
Changing to the right directory
In the cd command cd means “change directory to:” and your destination must specify either the precise location in the filesystem hierarchy —from the root down— or else the location relative to the directory into which you are currently logged. An example of the precise location would be:
cd /home/silverbear/Shared
An example of changing directories in a relative destination would be —if I were already logged in to my home directory:
cd Shared
As you would expect, unless I am already logged into /home/silverbear I am not going to get into the location /home/silverbear/Shared by using the relative specification!
Listing the files
The ls command means “list” the files in the current directory. Various switches added to the command give you different useful output. My advice is get used to just using the ls -l or ls -al forms most of the time. They give you a maximum amount of useful info in an orderly, tabular list form. The ls -al form includes all files, including the hidden ones, whereas the ls -l form omits listing the hidden files. If you run both variations while logged into your /home/user directory, you'll see that the ls -al variation can sometimes give you too much info that you don't need. But when you need to see it all, that's how to get it all.
Remote viewing
If you don't intend to run any commands that require you to actually be logged into a particular directory, you can view it's contents from wherever you are by add int location you wish to view. While logged into you home directory, for example, you can see what's in /etc/udev by typing in your terminal:
ls -al /etc/udev
Permission codes
In case you didn't read the Harvey Mudd College article on permissions, here is a brief chart. There are two ways of denoting permissions: by letter code and by numerical code.
Permissions by the numbers:
Octal Number Letter meaning 4 r read 2 w write 1 x execute 0 none
The octal permissions are additive. Hence, the following combinations are possible:
7 rwx read + write + execute 6 rw read + write 5 r-x read + execute 4 r-- read only 3 -wx write + execute [rare] 2 -w- write only [rare] 1 --x execute only [rare]
The top four are the usual variants. For obvious reasons, you rarely see the bottom 3 except as an error.
Directory listing of permisions
The initial string of characters in a directory listing will show the file type plus the permissions.
The ls -l command will show an entry like this for each file in a directory:
The initial - [hyphen] symbol indicates that this is a regular file. If it were a directory or another type of special file, the first letter would be as given in the list The Seven Unix/Linux File Types
The next cluster of 3 characters gives the user permisions. In this context user means the owner of the file, as listed.
The second cluster of 3 characters gives the permissions granted to other members of the group owning the file, as listed.
The last cluster of 3 characters indicates permission for others who encounter the file.
Remember the permission sets as occuring in this order: u g o Those letters will be of use later on when you learn how to change file permissions on the command line.
In the above diagram, the file is a regular file, and all three classes of users, u g and o, have complete rwx privileges.
How do File Permissions get set?
A fanciful tutorial, mercifully short
Step 1: create a new file
Your Linux system is set up with certain defaults in setting file permissions when creating a file. As an experiment, open a terminal window. Most likely it will open by default in the directory /home/username. This usually shows up in the prompt as [~]: the tilde symbolizes your user home directory. Now create a file by typing:
touch zzztestfile001
The "z's" are so it will wind up near the bottom of the filelist and be easy to find. Then run this command and see what the default permissions are set to for your new file.
ls -l
Here is what that one line for my new file looks like:
-rw-r--r-- 1 silverbear bears 0 2007-06-07 18:57 zzztest001
The owner is silverbear and the owning group is bears. It has a file size of zero and was created on the listed date and time. It's not one of a special class of files [see this section above] so the first character in the permissions string is a “–” instead of a letter. By default everyone can read the file, but only myself —not the rest of the world nor even other bears, can write to it. The Bash shell listing these files seems to understand that it is not a script or prog, so no-one is given execute permission.
How to Change File Permissions: meet chmod
Many times you will not be satisfied with the default permissions a file has. Our example above was an empty file created with the touch command but without any content. Suppose it had been a memo from myself to other members of the bear group, offering times to sign up for helping to prepare the Annual Salmon Dinner. Everyone's invited to the dinner —but only bears are involved in the prep work.
So I don't care if everyone can read the file. They're going to be invited to the event anyway. But I need bears —and only bears— to be able to write in their names in their preferred time-slot on my schedule. So I'll issue the appropriate chmod command and then list the file permissions and see if it looks right:
chmod g=rw zzztestfile001
ls -l
-rw-rw-r-- 1 silverbear bears 0 2007-06-07 18:57 zzztest001
That's it! Now I and other bears can read and write, but ordinary users can only read.
For the meeting minutes of our plotting session to capture Alaska, Yukon and northern B.C and declare the Independent Kingdom of Bearsylvania, we'd rather not have anybody at all see those —except bears. And I don't want them changing anything in the document. So here's what I'd do:
chmod g=r zzztestfile001
chmod o= zzztestfile001
ls -l
-rw-r----- 1 silverbear bears 0 2007-06-07 18:57 zzztestfile001
Now only I, the file owner can write to the file, Other members of the bears group can read-only, and users who are not bears don't even get to read it.
chmod guidelines
- Syntax: command assignment filename
Where command is chmod and filename is the target of your permissions changes. The assignment takes a few possible variations on the basic assignment statement below: - assignment : class=permissions
class refers to the class of user, and permissions means the new assignment of read write execute powers - Classes: u g o a
u is "you," the user/owner; g is group; o is others; a is ugo together: all classes - Permissions: r w x
read the contents of a file or view the filelist of a directory or block device
write or delete contents of a file, or create or move files in a directory or block device.
execute a file that is script or program.
. . .to be continued. . .
Also see these companion articles on the issue of configuring your system for access to data storage partitions:
Internet Explorer?