Also see these companion articles on the issue of configuring your system for access to data storage partitions:
Permission problems in Accessing your Data? Try Group Therapy!
Additional Linux Tricks for Secure but Accessible Data Directories
Especially in multi-user environments, a secure scheme for sharing data can become complicated. But it doesn't have to be! In Unix/Linux, the inherent filesystem concept of Permissions can make life both easy & safe. What's not to like about that?
Wikipedia has a good, not-too-complicated introduction to the concept and implementation of File System Permissions in Unix-based filesystems such as the ones Linux uses. The below link is to an external site: you may want to right-click and open it in a new window or tab in order to keep your place here.
The “SilverBear method” of using file permissions is nothing original. Unix computer systems that have dozens or hundreds of users employ it all the time. It involves the skilfull organization of users into groups.
Hypothetical Scenario #1
Let's take an example. SilverBear stores 5 GB of sensitive data about the projected honey harvest from New York State apiaries. He also has a directory of pictures of goats, organized by breed and milking capacity. He also has the complete recorded works of Beethoven in mp3's in another directory. All of these directories [which may or may not be separate partitions —it doesn't matter]. What does matter is that all of these directories are mounted at boot time.
User Giles needs to access the goat-related information when he logs in. But he also likes to listen to the 6th Symphony "Pastoral." As far as the honey-related data -umm, it's really none of his business. User BrownBear needs to access the honey-related data, but hates goats and will delete any goat pictures she sees. [Filthy things!] However, she also likes Beethoven.
But as it stands, none of them can access or change any of the files in any of those directories. Here is a “list files” command with the option to show all permissions:
Sample directory listing #1
ls -al drwxrwxr-x 17 root root 488 2007-04-29 22:55 . drwxrwxr-x 34 root root 4096 2007-04-29 14:43 .. drwxrwx--- 2 root root 88 2007-05-03 17:30 01-admin drwxrwx--- 9 root root 216 2007-04-29 16:58 01-backups drwxrwx--- 3 root root 144 2007-04-30 17:31 beethoven drwxrwx--- 4 root root 616 2007-04-30 12:49 caprines drwxrwx--- 3 root root 1208 2007-04-30 14:14 honeydata
In the leftmost column: d = directory. The next 9 characters should be interpreted in groups of three:
rwx for user [who owns the file], rwx for group and rwx for others, AKA “world ”—in other words, “the public,” “hoi-polloi,” or for you other old farts, “Joe Schmo”. I belabour the point to stress that opening this last triplet of permissions is where security is made or broken. You do not want “Joe Schmo” having access to everything, just because he happens to be at your keyboard, or has logged in via remote access somehow.
Summary. Learn these codes:
Permission codes:
r = permission to read
w = permission to write
x = permission to execute a program or script.
People codes
u = user who owns the file
g = group who owns the file
o = other users
Later, you will combine the three people codes with the three permission codes in various commands to set file permissions.
4 examples of some possible file permission schemes for a directory
. . . spaced out so you can see the groups of three:
rwx rwx rwx rwx rwx r-x rwx rw- r-- rwx r-- ---
1st line— read, write and execute permissions exist for all.
2nd line— User has rwx, so do group members, but others cannot write to the directory.
3rd line— Only the user has full rwx in this directory; the group can read & write but not execute; others can only read.
4th line— Strict! Group members can read, but not write to the directory; regular users can't even open it to see what's in it!
Note that in the differing circumstances wherein file permissions are applied to different file types, the permissions mean slightly different things. If this were were a text file, no read permission would mean you couldn't open it to see the text. If this file is a directory, no read permission means you can't see the contents of the directory. A directory is just a file with a list of other files: no read, no get list.
How do File Permissions get set?
Your Linux system is set up with certain defaults in setting file permissions when creating a file. As an experiment, open a terminal window. Most likely it will open by default in the directory /home/username. This usually shows up in the prompt as [~]: the tilde symbolizes your user home directory. Now create a file by typing:
touch zzztestfile001
The "z's" are so it will wind up near the bottom of the filelist and be easy to find. Then run this command and see what the default permissions are set to for your new file.
ls -l
Here is what that one line for my new file looks like:
-rw-r--r-- 1 silverbear bears 0 2007-06-07 18:57 zzztestfile001
It's not a special class like a directory or a block device, so this entry starts with a simple hyphen to indicate the filetype. For more information about the 7 filetpyes in Linux, see:
The next 3 characters indicate that the file owner can read, write [no execute], group members can read only [no write or execute] and "the world at large" can also read-only [no write or execute].
OK. . . so what?
So let's put together some solutions to the problems outined in Hypothetical Scenario #1.
Problem 1: Only root can read or write to these directories! We want to fine-tune user access to read and write privileges.
SilverBear's #1 solution: Group Therapy:
Assigning files to the ownership of groups, and then assigning users to membership in the group allows Giles and BrownBear to access what they need. There are three main steps to the process.
Step 1: Create functional user groups
Step 2: Change group ownership of the required file and directories.
Step 3: Change file permissions to allow what access we want for each group.
Step 4: Assign users to the appropriate group.
There is a Command Line Interface approach, and a Graphic User Interface approach to this System Administative job. The GUI approach will differ according to what Linux distro you are using. I'll give the GUI approach for KDE under MEPIS Linux later. First I'll give the CLI approach based on using a bash terminal in a Debian Linux system, which will probably be applicable to other families of Linux distros, but I haven't tested that assumption, so you test it step by step to see if it works before relying on it.
Internet Explorer?