File Permissions in the Shell

In Chapter 4, I showed you how to look at file permissions with Nautilus. When you use the ls -l command, you are doing the same thing; look at basic Linux security at the file (or directory) level. Here is an example of a long ls listing:

 $ ls -l total 3 drwxr-x---  5 root     system   512  Dec 25 12:01   presents -r-xr--r--  1 zonthar  users    123  Dec 24 09:30   wishlist -rw-rw----  1 zonthar  users    637  Nov 15 09:30   griflong 

The first entry under the total column shows a directory (I'll talk about the next nine characters in a moment). The first character is a d, which indicates a directory. At the end of each line, you find the directory or filenamein my example, they are presents, wishlist, and griflong. Because the first character in the permissions field is d, presents is a directory.

The other nine characters (characters 2 through 10) indicate permissions for the user or owner of the file (first three), the group (second group of three), and others or everyone else (last three). In the first line, user root has read (r), write (w), and execute (x) permissions, whereas the system group has only read and execute. The three dashes at the end imply that no one else has any permissions. The next two files are owned by the user called zonthar.

Quick Tip

Remember user, group, and other (ugo). You will find them useful later when I cover changing file and directory permissions.

Not-So-Hidden Files

When you take your first look at valid filenames, remember that I mentioned that files starting with a period are hidden. As a result, creating directories or files in this way is a favorite trick of system crackers. Get used to the idea of listing your directories and files with a -a option so that you see everything that's there. Look for anything unusual.

Keep in mind, however, that a number of applications create dotted directory names in your home directory so that you are generally not burdened with seeing all these configuration areas. That's great, except that you should know what you've got on your disk. Always balance your need for convenience with a healthy curiosity. A quick ls a in your home directory shows you some files (and directories) you will become very familiar with as time goes on. Here is an example of what you will see:

.Xauthority .bash_history  .bash_profile  .gnupg  .gnome2 

Strange Filenames That Just Don't Go Away

Every once in a while, you do a listing of your directory and some strange file appears that you just know isn't supposed to be there. Don't panic. It's not necessarily a cracker at work. You may have mistyped something and you just need to get rid of the error. The problem is that you can't. Case in point: I accidentally created a couple of files with hard-to-deal-with names. I don't want them there, but trying to delete them does not work. Here are the files:

-another_file  onemorefile 

Here's what happens when I try to delete them:

$ rm -another_file rm: invalid option -- a Try 'rm --help' for more information. 

What about that other file?

$ rm onemorefile rm: cannot remove 'onemorefile': No such file or directory 

The problem with the first file is that the hyphen makes it look like I am passing an option to the rm command. To get around this problem, I use the double-dash option on the rm command. Using two dashes tells the command that what follows is not an option to that command. Here I go again:

$ rm -- -another_file $ 

Bravo! By the way, this double-dash syntax applies to many other commands that need to recognize potentially weird filenames. Now, what about the second file? It looked fine, didn't it? If you look very closely, you see that there is a space in front of the leading o, so simply telling rm to remove the file doesn't work either, because onemorefile is not the filename. It is actually "onemorefile" (preceded by a space). So, I need to pass the space as well; to do that, I give the full name (space included) by enclosing the filename in double quotes.

$ rm " otherfile" $