/bin – Essential command binaries, such as ls, cp, cd, ... are stored here. These are commands that must be installed locally (i.e., not on a network)
/boot – Files used for booting the system, such as the kernel binary and various other files for the boot loader, reside here.
/dev – Under Linux, everything is either a file or a directory, and this directory proves it. /dev contains files through which your devices are accessed. For example, copying the data from /dev/fd0 gives you an image of the disk in the first floppy drive, sound is sent through /dev/dsp if you're using a program that uses OSS, and data to be printed goes through /dev/lp0. Don't worry; data sent to devices does not take up any space on your hard drive! Originally, the /dev directory had real files on the hard disk for each device, but a /dev directory with about 300 device files uses under 100K of space. One problem was that there was no organization of the devices; everything was simply placed in /dev. Another problem was that after installing a new driver, the root user had to create the device nodes necessary to use the device. Conversely, there often were many device nodes that were unnecessary. (Who needs, or has, 256 SCSI hard drives, anyway?) Not only that, but this method was relatively slow... In addition, since each device node contains two numbers (major and minor) from 0 to 255 that identified what kind of device it was, there was a limit on the number of possible device types, not to mention the fact that driver developers outside the Linux kernel team have to obtain their official device numbers to avoid conflicts. Then came devfs. Devfs is a solution to all these problems. It creates a RAM-based /dev directory that is automatically managed by the kernel and a program called devfsd. This solves many problems with the /dev directory. It organizes the /dev directory into subdirectories. Unfortunately, this would break compatibility with a lot of programs, but there's a solution: create links using the old names that point to the new file. This basically undoes the organization of the devices, but the best part is that the link are added and removed automatically as well! Devfs also removes the major/minor number limitations of the disk-based implementation by making device access by making the device drivers addressed by name rather than number. The only drawbacks are that drivers that don't support devfs must still use major/minor number notation, meaning that device nodes must be re-created in /dev somehow every time the system is booted (due to the fact that devfs is RAM-based); devfs uses more memory than a disk-based /dev directory, but devfs uses under 1 MB of memory even on computers with a lot of device nodes; and, unless you save the /dev state using devfsd (it's really easy to set that up), devfs will not retain the file permissions. To enable this on your system, install devfsd and compile your kernel with devfs and say "yes" to the option to mount it automatically at boot time. Devfsd is included with Debian and possibly other Linux distributions. To tell if you are using devfs, get to a command line session and type 'cd /dev' followed by 'ls -a .devfs'. If you see '.devfs' listed, then you have devfs already installed. If it's not listed, then you don't have it installed.
/etc – This directory contains the system-wide configuration files. Files in this directory can only be written to as root.
/home – This contains user home directories. Users can put anything they want in their home directories. User home directories also contain various hidden configuration files and directories (i.e., application preference settings). To see them, go to your home directory (type 'cd' without any parameters) and type 'ls -a'. Any filename beginning with a dot is hidden. To see them in Konquerer (KDE's file manager), go to View, Show Hidden Files. To lock your home directory so that other users (except root) cannot enter your home directory, get to a command line and type 'cd /home' followed by 'chmod go-rwx username', replacing username with your user name.
/lib – This contains vital system libraries that must be stored locally and be available upon boot. This directory also contains kernel modules.
/lost+found – This directory is present on every ext2 & ext3 (Linux) partition. If, when fsck does a file system check, it finds any lost data (due to misallocation, or whatever), it places the lost data into this directory. Only root can even access this directory.
/mnt – This contains system mount points. For example, my DOS partitions are mounted in the directories /mnt/dos0 and /mnt/dos1. On some distributions, this is where the floppy and CD-ROM mount points are, but, on my Debian boxes, I have the mount points /floppy (for my 3.5" floppy), /floppy1 (for my 5.25" floppy), and /cdrom (for my CD burner or CD-ROM drive) instead of /mnt/floppy, /mnt/floppy1, and /mnt/cdrom.
/opt – Under Windows, each program gets its own directory in C:\Program Files. In Linux, there are three ways a program can be installed and organized. If you install it as a binary package (.deb or .rpm), it goes into /usr, and the files get organized by function. If you install it from source code, it is most likely installed into /usr/local, and the files again get organized by function. If you install a major software program like OpenOffice.org, it may go into either /usr/local, where the files are organized by function or into /opt, where the program makes its own directory and puts all its files in that directory, thus making it organized by context rather than function. Think of /opt as Linux's 'Program Files' directory.
/proc – This directory contains a virtual file system. The proc file system contains files that are stored in memory and give information about the system. Many system information utilities really only report what's in the files in this directory. The files present here are, for the most part, human-readable text.
/root – This is the root user's home directory. In the earlier Unices, the root had the root directory for a home directory, hence the name 'root', but modern Unices use /root to avoid cluttering up the root directory.
/sbin – This directory contains system command binaries that must be stored locally. For example, init (the system runlevel manager), insmod/rmmod/modprobe (tools to insert/remove kernel modules), login managers, and various other important administrative and system executables reside here.
/tmp and /var/tmp – These are temporary directories. In Windows, the directory C:\WINDOWS\TEMP serves this same purpose. On Linux the temporary directories are cleaned up automatically upon boot in most distributions. Windows Setup, however, disables any commands in AUTOEXEC.BAT that clean up the temporary directory. What a bunch of morons they are at Micro$oft!
/usr – This is complicated to explain, but here goes.... In the original Unix versions, /usr was where user home directories were. That is, /usr/djb would have been what /home/djb is today. In modern Unices, /usr is where 'user-land' programs and libraries reside. 'usr' now can be taken to stand for 'User System Resources'. This is the biggest directory on a Linux system unless, like me, you have a lot in your home directory.... The next several bullets attempt to explain what all this stuff is. Believe me, it ain't pretty! :(
/usr/X11R6 – This is where the X Window System-related stuff is supposed to go... This is another large directory structure. It is not very well-organized. In fact, many X-related programs don't even install themselves here! This mess is due mostly to the fact that in Linux, unlike most other modern operating systems, the graphical desktop is not a vital, integral part of the operating system. (I actually prefer it that way. It makes things a lot more stable, more flexible, and faster!)
/usr/bin -- This is where most of the binaries on your system are located. Binaries here are for things like development tools, multimedia, graphics programs, editors, etc. Like the other binary directories, these are only executables—nothing else, and they're not further organized by program.
/usr/doc – This is a link to /usr/share/doc. See /usr/share/doc for more information.
/usr/etc – This is another directory for configuration files, like /etc, but it's virtually unused now.
/usr/games – This is where some game binaries are stored. However, many games are stored in /usr/bin instead.
/usr/include – This directory contains header files for C, C++, FORTRAN, assembly, and other programming languages.
/usr/info – This is where documentation in 'info' format (for the 'info' program) was stored. Now it's a link pointing to /usr/share/info.
/usr/local – This directory contains another hierarchy with an identical structure to /usr (but without 'local'--otherwise, the file system would become recursive, and we'd have the possibility of having /usr/local/local/local/local/local/local/local/local/local/local/local/local/local/local/...!) The original idea behind this directory was to have a /usr structure stored locally, assuming /usr was mounted read-only across a network. However, /usr/local is used today to allow the installation of software that is not installed via a packaging system like dpkg and rpm. On most Linux distributions, /usr is controlled by the packaging system, while /usr/local is under the user's control. This is similar to /opt, except that files in /usr/local are arranged by function, while files in /opt are arranged by context.
/usr/man – It was once used for manual pages (viewed with the man command). However, they moved to /usr/share/man, and this is now a link to that directory.
/usr/sbin – Here's where the administrative programs are stored. These commands are meant to be run by 'root' and not by a normal user, and they won't work without root privileges.
/usr/share – This is where program data that doesn't need to be modified goes. These files are architecture-independent. This data can be shared among users, but not among different operating systems. There should be one subdirectory for each program that stores its data here, plus a few common subdirectories that I'll mention below. Program data that does need to be modified goes into /var. See /var for more information.
/usr/share/doc – Some useful documentation that comes with software goes here. This directory has one subdirectory for each program that has documentation. This directory is linked to from /usr/doc.
/usr/share/info – Info documents go here. Typing 'info' at the command prompt, optionally followed by the name of a topic, brings up these documents.
/usr/share/man – Man pages go here. Typing 'man' followed by a valid topic brings up these man pages. In the file system, the man pages are organized by chapter. In older versions of 'man', you had to specify a chapter number, but that's no longer required. The directories and chapters are:
man1 – Chapter 1 – User Programs
man2 – Chapter 2 – System Calls
man3 – Chapter 3 – Library Functions and Subroutines
man4 – Chapter 4 – Special Files
man5 – Chapter 5 – File formats
man6 – Chapter 6 – Games
man7 – Chapter 7 – Miscellaneous
man8 – Chapter 8 – System Administration Tools
/usr/src – Source code distributed via your distribution's packaging software gets installed here. The Linux kernel source code goes here, too.
/var – Dynamic data like caches, logs, mail, and printer spool directories goes here. This is data that needs to be able to change.
For more information on the file system hierarchy, visit http://www.tldp.org and look for the Linux file system hierarchy guide, in the guides section, by Binh Nguyen. Many thanks go to him for writing that guide. I looked at it a lot while I was writing this section. His guide goes into much greater detail than my guide goes.
PART 2: DIFFERENCES BETWEEN THE LINUX AND WINDOWS FILESYSTEMS
In Linux, as I mentioned before, pathnames use / instead of \ to separate directories. In fact, DOS and Windows are the only operating systems in the world to use the \ to separate directories! Every other operating system, except Mac OS, uses / to separate directories in pathnames. (Mac OS uses the colon.) Another difference, as I mentioned earlier, is that Linux is case-sensitive in filenames. This stems from the fact that C, and other early programming languages, are case-sensitive.
Linux and Windows organize their files very differently. In Linux, the files are organized by function. That is, libraries go in a directory together, executables go in other directories together, and documentation goes somewhere else. In Windows, the files are arranged by context. That is, files for one program go in one directory, files from another program go in another directory, and the Windows directory is a disorganized mess. :)
In Linux, most of the directories can't be changed by normal users. This is to prevent virus infections from wiping out the system. Normal users have to 'go root' to install software into those directories. User home directories are for anything you want. Under Windows, however, virus threat is so common because the default setup is to give the user administrative permissions 100% of the time, thus allowing unwanted programs to tamper with the system files because the system files are not locked.
Linux and Unix have file permissions and owners, while Micro$oft Windows doesn't.
Under Linux, all drives and partitions become part of a single root file system. Under Windows, there are drive letters. For more information on mounting and unmounting filesystems, see my Bash prompt guide, which explains the command line.
Despite the fact that I grew up using Windows, I personally prefer the Unix way of doing things. I think it's very nice to be able to just type a the name of a program's executable from any directory and have the program run. I know it's possible to set that up in Windows, but in Windows, registry entries telling where the program executable is and/or a search path is needed. Under Unix, the executables are all in four directories that contain just executables. Another nice thing is that, since the files are arranged by function, absolute paths are allowed when referencing a program or its data, and the installation directory is going to be the same on every system, thus eliminating the need to keep track of where the user installed it.
PART 3: FILE PERMISSIONS
Linux, like Unix, is a very secure, multiuser operating system. This adds a little bit of complexity to the way file permissions are handled. If you have problems with file permissions, you can have some nasty problems... Thus, it is a good idea to learn about how file permissions work in Linux.
FILE OWNERSHIP
Each file is owned by a user and a group. The user is usually someone's login name. The group may consist of multiple users, but it is often just a one-person group with the user's name. To see who owns a file, you can look in your file manager's properties window, or you can use 'ls -l filename' at the command prompt. Here's what the 'ls -l' method might look like on my computer for these Linux guides:
djb@tty1:~/linux-guides$ ls -l
total 192k
-rw-r--r-- 1 djb djb 7.3k Jun 15 23:49 00Readme.html
-rw-r--r-- 1 djb djb 26k Jul 7 21:55 Command-Line-BASH.html
-rw-r--r-- 1 djb djb 12k Jul 7 16:05 Compiling-the-Linux-Kernel-in-Debian.html
-rw-r--r-- 1 djb djb 6.2k Jul 9 14:34 Disk-Images.html
-rw-r----- 1 djb users 6.8k Jun 15 10:04 FAT-partitions.html
-rw-r--r-- 1 djb users 18k Jul 9 14:46 Filesystem-and-Permissions.html
-rw-r--r-- 1 djb djb 9.2k Jun 15 10:29 Installing-Debian-486.html
-rw-r--r-- 1 djb djb 8.8k Jun 15 10:49 Installing-Debian-Pentium.html
-rw-rw-rw- 1 djb djb 5.7k Jul 7 14:00 Installing-from-source-code.html
-rw-r--r-- 1 djb djb 5.2k Jun 15 21:57 TiMidity.html
-rw-r--r-- 1 djb djb 6.4k Jun 15 11:18 Using-TrueType-Fonts.html
-rw-r--r-- 1 djb djb 30k May 31 22:26 fdl.html
-rw-r--r-- 1 djb djb 26k May 31 22:17 gpl.html
The format for the display is:
permission #itm user group size date/time filenamename
In the example, the owner and group for most files are both 'djb', which is my login name. Some have the group name 'users'. The owner can be changed with the 'chown' command as root. For example, I can change the owner of 'fdl.html' to user 'rms' and group 'fsf':
root@tty1:/home/djb/linux-guides# chown rms:fsf fdl.html
I can also just change the owner of the file without changing the group:
root@tty1:/home/djb/linux-guides# chown rms fdl.html
Alternatively, I can change the group without changing the owner via the 'chgrp' command:
root@tty1:/home/djb/linux-guides# chgrp fsf fdl.html
Note that, unless you currently own the file(s) you're working with, you must be root to use these commands.
By default, the owner of a file is who created it.
FILE PERMISSIONS
In order to understand file permissions, you need to first know how file ownership works. That was the purpose of the last section.
File permissions come in five varieties: r, w, x, s, and t. Here's a table that outlines what each permission means for files and directories:
|
Table 1: Permissions and Their Meanings |
||
|---|---|---|
|
Permission |
Files |
Directories |
|
r |
Read the file |
Read directory entries |
|
w |
Write to the file |
Write entries |
|
x |
Execute file |
Enter directory |
|
s |
Set user/group ID when executing |
Sets a default group ID for files in a directory |
|
t |
Does nothing |
Sticky |
There are three classes of users when dealing with permissions: the user who owns the file (user, u), users in the group that owns the file (group, g), and everyone else (others, o). Let's refer back to the directory listing I gave earlier in the file ownership section. To refresh your memory:
djb@tty1:~/linux-guides$ ls -l
total 192k
-rw-r--r-- 1 djb djb 7.3k Jun 15 23:49 00Readme.html
-rw-r--r-- 1 djb djb 26k Jul 7 21:55 Command-Line-BASH.html
-rw-r--r-- 1 djb djb 12k Jul 7 16:05 Compiling-the-Linux-Kernel-in-Debian.html
-rw-r--r-- 1 djb djb 6.2k Jul 9 14:34 Disk-Images.html
-rw-r----- 1 djb users 6.8k Jun 15 10:04 FAT-partitions.html
-rw-r--r-- 1 djb users 18k Jul 9 14:46 Filesystem-and-Permissions.html
-rw-r--r-- 1 djb djb 9.2k Jun 15 10:29 Installing-Debian-486.html
-rw-r--r-- 1 djb djb 8.8k Jun 15 10:49 Installing-Debian-Pentium.html
-rw-rw-rw- 1 djb djb 5.7k Jul 7 14:00 Installing-from-source-code.html
-rw-r--r-- 1 djb djb 5.2k Jun 15 21:57 TiMidity.html
-rw-r--r-- 1 djb djb 6.4k Jun 15 11:18 Using-TrueType-Fonts.html
-rw-r--r-- 1 djb djb 30k May 31 22:26 fdl.html
-rw-r--r-- 1 djb djb 26k May 31 22:17 gpl.html
The first column, the file permissions, is what we're focusing on now. Here's how it's arranged, broken up to make it easier to show:
type | user | group | other
- rwx rwx rwx
(Permissions 's' and 't' shows up in the 'x' column when it's set.)
For example, the file above named 'FAT-partitions.html' has a permissions column of 'rw-r-----', meaning the owner has the read and write permission, members of the group have read-only permission, while everyone else cannot even read the file.
The command 'chmod' changes file permissions, provided you are either root or the user who owns the file. The syntax is 'chmod mode file'. The mode can be an octal number or in the form of a user class (u for user, g for group, o for others, a for all), a + or – sign (for on or off), and then a permission (r for read, w for write, x for execute, X to make it so that execute is changed only if the file is a directory OR if the execute permission is already set). The file can be a wildcard. Here are some examples
chmod 666 fred.txt --- Enables everyone to read and write to 'fred.txt'
chmod ug+rwx jim --- Enables the file owner and members of the group that's associated with the file 'jim' to read, write, and execute it.
chmod u+w,go-w,a+x sheila.sh --- Enables the owner to write to 'sheila.sh', prevents others (except root) from writing to it, and allows everybody to execute it.
chmod a-r,a+w,a-x barney.foo --- Sets some weird permissions for 'barney.foo': nobody except root can read the file, everybody can write to the file, and nobody can execute the file. This set of permissions is not very common except on some device nodes in /dev.
Does the explanation look familiar? I 'borrowed' it from my command line guide.
The octal representation of the file permissions is shorthand. There are three digits, one for each of user, group, and other. Each permission type (r, w, x) has a certain value. When the values of the active or desired permission(s) are added together, the sum produces a digit. The value of each permission follows.
|
Table 2: The Values of the Permissions in Octal Representation |
|
|---|---|
|
Permission |
Value |
|
Read [r] |
4 |
|
Write [w] |
2 |
|
Execute [x] |
1 |
Thus, the meaning of each possible digit:
|
Table 3: The Possible Digits of Octal Representation |
|
|---|---|
|
Digit |
Meaning |
|
0 |
no permissions at all (common) |
|
1 |
execute only (seems unusual) |
|
2 |
write only (seems unusual) |
|
3 |
write and execute (seems unusual) |
|
4 |
read only (common) |
|
5 |
read and execute (common) |
|
6 |
read and write (common) |
|
7 |
read, write, and execute (common). |
A common octal permission is 666: read and write permission for everybody. For some people, this is proof enough that Linux, as well as any Unix, is the work of the devil... >:-O
Octal representation is base 8, and it comes from the binary representation of the permissions. Here's an example (and another table).
|
Table 4: Example: Binary and Octal Representations of Permissions |
||||
|---|---|---|---|---|
|
Representation |
User |
Group |
Others |
Complete |
|
ls -l |
rwx |
r-x |
--x |
rwxr-x--x |
|
Binary |
111 |
101 |
001 |
111101001 |
|
Octal |
7 |
5 |
1 |
751 |
You never have to use octal format for specifying permissions, but it may come in handy.
Now, about the 's' permission. The 's' permission is special. It is used to make a program 'think' it's being run by a different user (i.e., the owner of the executable file), and, as a result, provide any special permissions that the user may have. This is most commonly used to give a program superuser (root) permissions even when run as a normal user. This is called 'setting suid'. This is most often required on X servers, svgalib programs, and other software that needs direct access to the hardware. To set a program suid, type the following as root, substituting filename for the name of the executable you wish to set SUID:
chmod u+s filename
Make sure you either specify a path to the executable or be in the directory that the executable is in.
To make an executable file set the group ID (SGID), use
chmod g+s filename
WARNING: Making a program SUID can be dangerous! If a program is SUID, the results can be disastrous if the program has any poorly-written or malicious code in it! This is not a problem in svgalib programs because svgalib drops the root permissions for the program at the beginning (svgalib needs root permissions to control the video card). Use caution! Suid programs do not have any security! Don't suid too many executables, either. I will NOT be responsible for anything that happens as a result of suiding a program that shouldn't be suid. You have been warned!
The 's' permission does a different thing on a directory. When used as a SUID bit, it has no effect. When a directory is SGID, it sets the default group to be used for files created in that directory.
The 't' permission is another special permission. If a directory is accessible (r, w, and x are all allowed) by more than one user, setting the 't' bit makes any move or delete operations fail if the current user doesn't own those files.
ACKNOWLEDGEMENTS
I referenced two guides extensively while writing this guide. For the file system hierarchy information, I would like to thank Binh Nguyen for his wonderful Linux File System Hierarchy guide, which is available at http://www.tldp.org. For the information on file permissions, I would like to thank the authors of the Linux Newbie Administrator Guide, which is available at http://linux-newbie.sunsite.dk. Both of those guides explain in further detail the way the filesystem works (among other things).
For the program I used to write this guide, I would like to thank the many authors of OpenOffice.org.