Earlier in this chapter, when you tried to cd to
root's login directory, you received the following message:
[newuser@localhost newuser]$ cd /root
bash: /root: Permission denied
[newuser@localhost newuser]$ |
That was one demonstration of Linux's security features. Linux, like
UNIX, is a multi-user system, and file permissions are one way the
system protects against any type of damage.
One way to gain entry when you are denied permission is to
su to root, as you learned earlier. That's
because whoever knows the root password has complete access.
[newuser@localhost newuser]$ su
Password: your root password
[root@localhost newuser]# cd /root
[root@localhost /root]# |
But switching to superuser isn't always convenient, or wise, since it's
easy to make mistakes and alter important configuration files.
All files and directories are "owned" by the person who created them. You
created the file sneakers.txt (see the section called Using Redirection in your login
directory, so sneakers.txt "belongs" to you.
That means you can specify who's allowed to read the file, write to the
file or, if it's an application instead of a text file, who can execute
the file.
Reading, writing, and executing are the three main settings in
permissions.
Since users are placed into a group when their
accounts are created, then you can also specify whether certain groups
can read, write to, or execute a file.
Take a closer look at sneakers.txt with the
ls command using the -l (long)
option (see Figure 10-12).
[newuser@localhost newuser]$ ls -l sneakers.txt
-rw-rw-r-- 1 newuser newuser 150 Mar 19 08:08 sneakers.txt |
There's a lot of detail provided here. You can see who can read (r) and
write to (w) the file, as well as who created the file (newuser) and to
which group the owner belongs (newuser).
 | Your default group |
|---|
| | Remember that, by default, your group is the same as your login
name.
|
Other information to the right of the group includes file size, date and
time of file creation, and file name.
The first column (shown above) shows current permissions; it has ten
slots. The first slot represents the type of file. The remaining nine
slots are actually three sets of permissions for three different
categories of users.
Those three sets are: the owner of the file, the group in which the file
belongs, and "others," meaning users and groups other than the owner of
the file (newuser), and those in newuser's group (which is also newuser).
- (rw-) (rw-) (r--) 1 newuser newuser
| | | |
type owner group others |
The first item, which specifies the file type, can show one of the
following:
Beyond the first item, in the following three sets, you'll see one of the
following:
When you see a dash in owner, group, or others, it means that particular
permission has not been granted.
Look again at first column of sneakers.txt and
identify its permissions. (See Figure 10-13)
[newuser@localhost newuser]$ ls -l sneakers.txt
-rw-rw-r-- 1 newuser newuser 150 Mar 19 08:08 sneakers.txt
[newuser@localhost newuser]$ |
The file's owner (in this case, newuser) has permission to read and
write to the file. It is not a program, so newuser doesn't have
permission to execute it. The group, newuser, has permission to read and
write to sneakers.txt, as well. Similar to the
program notation for owner newuser, there's no
execute permission for group newuser.
In the last set, you can see that those who aren't either the user
newuser or in the group called newuser can read the
file, but can't write to it or execute it.
Change the permissions on sneakers.txt with
the chmod command.
The original file looks like this, with its initial permissions
settings:
-rw-rw-r-- 1 newuser newuser 150 Mar 19 08:08 sneakers.txt |
If you are the owner of the file or are logged into the root account you
can change any permissions for the owner, group, and others.
Right now, the owner and group can read and write to the file.
Anyone outside of the group can only read the file
(r--).
 | Permissions Are Necessary |
|---|
| | Remember that file permissions are a security feature. Whenever you
allow everyone to read, write to, and execute files, you are
increasing the risk of files being tampered with, altered, or
deleted. As a rule, then, you should only grant read and write
permissions to those who truly need them.
|
In the following example, you want to allow everyone to write to the
file, so they can read it, write notes in it, and save it. That means
you'll have to change the "others" section of the file permissions.
Since you're the owner of the file, you don't have to
su to root to do it. Take a look at the file
first. At the shell prompt, type:
The previous command displays this file information:
-rw-rw-r-- 1 newuser newuser 150 Mar 19 08:08 sneakers.txt |
Now, type the following:
To check the results, list the file's details again. Now, the
file looks like this:
-rw-rw-rw- 1 newuser newuser 150 Mar 19 08:08 sneakers.txt |
Now, everyone can read and write to the file (Figure 10-14).
The o+w command tells the system you want to give
others write permission to the file sneakers.txt.
To remove read and write permissions from
sneakers.txt use the chmod
command to take away both the read and write permissions like so:
and the result will look like this:
-rw------- 1 newuser newuser 150 Mar 19 08:08 sneakers.txt |
By typing go-rw, you are telling the system to
remove read and write permissions for the group and for others from the
file sneakers.txt.
You might think of these settings as a kind of shorthand when you want
to change permissions with chmod, because all you
really have to do is remember a few symbols and letters with the
chmod command.
Here a list of what the shorthand represents:
Identities
u — the user who owns the file (that is,
the owner)
g — the group to which the user belongs
o — others (not the owner or the owner's group)
a — everyone or all
(u, g, and
o)
Permissions
r — read access
w — write access
x — execute access
Actions
+ — adds the permission
- — removes the permission
=—makes it the only permission
 | An Additional Permission |
|---|
| | Another permission symbol is t, for the sticky
bit. If a sticky bit is assigned to a file, a user who wants to remove
or rename that file must own the file, own the directory, have write
permission, or be root (see the section called File Properties in Chapter 11).
|
Want to test your permissions skills? Remove all permissions from
sneakers.txt — for everyone.
Now, see if you can read the file:
[newuser@localhost newuser]$ cat sneakers.txt
cat: sneakers.txt: Permission denied
[newuser@localhost newuser]$ |
It worked. But since the file belongs to you, you can always change its
permissions back (see Figure 10-15).
[newuser@localhost newuser]$ chmod u+rw sneakers.txt
[newuser@localhost newuser]$ cat sneakers.txt
buy some sneakers
then go to the coffee shop
then buy some coffee
bring the coffee home
take off shoes
put on sneakers
make some coffee
relax!
[newuser@localhost newuser]$ |
Here are some common examples of settings that can be used with
chmod:
g+w — adds write access for the group
o-rwx — removes all permissions for others
u+x — allows the file owner to execute the file
a+rw — allows everyone to read and write to
the file
ug+r — allows the owner and group to read the
file
g=rx — lets the group only read and execute (not
write)
By adding the -R option, you can change permissions
for entire directory trees.
Because you can't really "execute" a directory as you would an
application, when you add or remove
execute permission for a directory, you're really allowing (or denying)
permission to search through that directory.
To allow everyone read and write access to every file in the
tigger directory in your login directory, type:
But… if you don't allow others to have execute permission to
tigger, it doesn't matter who has read or write
access, because no one will be able to get into the directory —
unless they know the exact filename they want.
For example, type:
to remove everyone's execute permissions.
Here's what happens now when you try to cd to into
tigger:
[newuser@localhost newuser]$ cd tigger
bash: tigger: Permission denied
[newuser@localhost newuser]$ |
Restore your own and your group's access.
Now, if you check your work with ls -dl you'll
see that only others will be denied access to the
tigger directory.
