Back in Chapter 5, I showed you how to look at file permissions with Konqueror. When you use the ls -l command, you are doing the same thing looking 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 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'll find the directory or filename in my example, they are presents, wishlist, and griflong. Because the first character in the permissions field is d, "presents" is a directory.
On to those other nine characters (characters 2 through 10). These 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, while 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.
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 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 will show you some files (and directories) you will become very familiar with as time goes on. Here is an example of what you will see:
Xclients .bash_history .bash_profile .gnupg .kde
Strange Filenames That Just Won't Go Away
Every once in a while, you will do a listing of your directory and some strange file will appear 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 just need to get rid of it. 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:
Here's what happens when I try to delete them:
[mgagne@scigate tmp]$ rm -another_file rm: invalid option -- a Try 'rm --help' for more information.
What about that other file?
[mgagne@scigate tmp]$ 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'll 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:
[mgagne@scigate tmp]$ rm -- -another_file [mgagne@scigate tmp]$
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'll see 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". So I need to pass that space as well, and to do that I give the full name (space included) by enclosing the filename in double quotes:
[mgagne@scigate tmp]$ rm " otherfile" [mgagne@scigate tmp]$