File Permissions in the Shell
Back in Chapter 5, I showed you how to look at file permissions with Konqueror. When you use the
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 -l
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
in a moment). The first character is a
, which indicates a directory. At the end of each line, you'll find the directory or filename—in my example, they are
. Because the first character in the permissions field is
, "presents" is a directory.
On to those other nine characters (characters 2 through 10). These
permissions for the user or owner of the file (first three), the group (second
of three), and others or everyone else (last three). In the first line,
root has read (
), write (
), and execute (
) 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
Remember user, group, and other (
). You will find them useful later when I cover changing file and directory permissions.
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
option so that you see everything that's there. Look for anything unusual.
Keep in mind, however, that a number of applications create
in your home directory so that you are
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
. A quick
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
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
a cracker at work. You may have
something and just need to get rid of it. The problem is that you can't. Case in point: I
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
command. To get around this problem, I'll use the double-dash option on the
command. Using two dashes
the command that what
is not an option to that command. Here I go again:
[mgagne@scigate tmp]$ rm -- -another_file
Bravo! By the way, this double-dash syntax applies to many other commands that need to recognize
weird filenames. Now, what about the second file? It
fine, didn't it? If you look very closely, you'll see a space in front of the leading
, so simply telling
to remove the file doesn't work either, because "
" is not the filename. It is actually "
". So I need to pass that space as well, and to do that I give the full
(space included) by enclosing the filename in double quotes:
[mgagne@scigate tmp]$ rm " otherfile"