One of the biggest learning curves facing the new Linux user is the file permissions system. I have vivid memories of my first Linux distribution, Red Hat 6.1. I had it on a machine not connected to the Internet, so I struggled for awhile with a two-tiered user/root system, then gave up and ran as root all the time. But in later distros, I learned (slowly) to come to grips with it. It grows on you! It helps that the file permission system is one of the main reasons that Linux has such a reputation for security.
File permissions have three categories of usage, and three categories of user. The user categories are owner, group, and anybody, and the usage categories are read, write, and execute. These bits are encoded numerically as a three-digit number. Perhaps a chart here will clear it up:
read write execute owner | 400 | 200 | 100 | group | 40 | 20 | 10 | other | 4 | 2 | 1 |
To set a file's permissions numerically, just pick the options you want and sum the digits! Then feed that as an argument to the chmod command:
$ chmod 777 ./my_file
turns on all permissions globally.
$ chmod 750 ./my_file
ensures that I have full access to "my_file", and members of my group can read it and execute it, but everybody else is locked out. If I wrote a shell script as root and dumped it into /usr/bin and wanted everybody to be able to use it, but not fiddle with it, I'd set it:
$ chmod 711 /usr/bin/my_script.sh
ensuring that anybody could execute it, but only I (in my lordly authority as system administrator) could read or write to it. Note that this is protection two ways: A virus running under Joe's user account can not write malicious code into my script, and a snooper from outside the system couldn't read any sensitive information in it. The most common setting is:
$ chmod 755 ./program_file
Which means "Everybody can read and execute this file, but only the owner (i.e. root) can modify it." Most everything on an installed Linux system has the owner set to "root", everywhere but within the home directories. Lastly, in the case of a non-executable file, you'd just say:
$ chmod 644 ./my_memo
everybody can read it, but only I can write it; nobody can execute it because it's not that kind of file.
File permission are also settable and readable as letters, in the form:
type|owner|group|other d rwx rwx rwx
viewable with the "-lh" argument to the "ls" command:
total 20K drwxrwxrwx 3 joe users 4.0K 2005-07-18 10:39 Desktop/ drwxrwxrwx 5 joe users 4.0K 2005-07-15 21:12 GNUstep/ drwxr-x--- 2 joe users 4.0K 2005-11-20 13:28 mobo_manual/ drwx------ 2 root root 4.0K 2005-12-28 15:45 Evals/ drwxrwxrwx 10 joe users 4.0K 2005-12-01 22:08 junk/ -rw------- 2 joe users 4.0K 2005-11-20 13:28 notes
"Joe's" home directory, showing that all the files but one are directories, and anybody can access his Desktop, GNUstep, or junk folder. "Joe" wants only himself to have full permissions to the motherboard manual he's writing, and he's allowing other users on his team to read it, hence the directory must be "executable" so others can see it's contents. "Joe" also keeps some private notes scribbled just for his use, and we see that root, the system administrator, also keeps his Evaluation files for "Joe's" project in "Joe's" home directory.
You can use this shortcut with chmod, as well. Typing
$ chmod +x ./my_script.sh
turns the shell script into an executable file for everyone. Typing
$ chmod go-r ./my_diary
keeps your diary from being read by anybody but you. The syntax is "ugo+/-rwx": use (u)ser, (g)roup, (o)ther to set who the access applies to, (+/-) to add or remove the permission, and (r)ead, (w)rite, (e)xecute to specify the kind of access.
Now, here's an interesting situation: what happens when you deny your own permissions?
$ cat >> test_file This is test data. There is no spoon. $ cat test_file This is test data. There is no spoon. $ chmod -r test_file $ cat test_file cat: test_file: Permission denied
Whoops! Now, what do I do? Well, since:
$ ls -lh
--w------- 1 me users 38 2006-01-02 14:25 test_file
I'm still the owner of this file, I can just
$ chmod +r test_file
and I can read it again. The same applies if I took away write permissions for myself - I'm still the owner, so I can delete it or change the permissions back.
Lastly, "root" is known as the "superuser" for a reason: root's privileges override all permissions:
$ chmod -rwx test_file $ cat test_file cat: test_file: Permission denied $ su password: *** # cat test_file I changed my mind. There is too a spoon. # ls -lh ---------- 1 me users 41 2006-01-02 14:35 test_file
This is just the basic overview of how the system works. Much deeper effects happen, because permissions also control what program (running as a given user or root's process) can access what file. But that's a whole new article in and of itself, and much more useful on a case-by-case basis. For now, this is meant as an introduction to the concepts.