Linux Directory Structure (File System Structure) Explained with Examples

Have you wondered why certain programs are located under /bin, or /sbin, or /usr/bin, or /usr/sbin?
For example, less command is located under /usr/bin directory. Why not /bin, or /sbin, or /usr/sbin? What is the different between all these directories?
In this article, let us review the Linux filesystem structures and understand the meaning of individual high-level directories.

1. / – Root

• Every single file and directory starts from the root directory.
• Only root user has write privilege under this directory.
• Please note that /root is root user’s home directory, which is not same as /.

2. /bin – User Binaries

• Contains binary executables.
• Common linux commands you need to use in single-user modes are located under this directory.
• Commands used by all the users of the system are located here.
• For example: ps, ls, ping, grep, cp.

3. /sbin – System Binaries

• Just like /bin, /sbin also contains binary executables.
• But, the linux commands located under this directory are used typically by system aministrator, for system maintenance purpose.
• For example: iptables, reboot, fdisk, ifconfig, swapon

4. /etc – Configuration Files

• Contains configuration files required by all programs.
• This also contains startup and shutdown shell scripts used to start/stop individual programs.
• For example: /etc/resolv.conf, /etc/logrotate.conf

5. /dev – Device Files

• Contains device files.
• These include terminal devices, usb, or any device attached to the system.
• For example: /dev/tty1, /dev/usbmon0

6. /proc – Process Information

• Contains information about system process.
• This is a pseudo filesystem contains information about running process. For example: /proc/{pid} directory contains information about the process with that particular pid.
• This is a virtual filesystem with text information about system resources. For example: /proc/uptime

7. /var – Variable Files

• var stands for variable files.
• Content of the files that are expected to grow can be found under this directory.
• This includes — system log files (/var/log); packages and database files (/var/lib); emails (/var/mail); print queues (/var/spool); lock files (/var/lock); temp files needed across reboots (/var/tmp);

8. /tmp – Temporary Files

• Directory that contains temporary files created by system and users.
• Files under this directory are deleted when system is rebooted.

9. /usr – User Programs

• Contains binaries, libraries, documentation, and source-code for second level programs.
• /usr/bin contains binary files for user programs. If you can’t find a user binary under /bin, look under /usr/bin. For example: at, awk, cc, less, scp
• /usr/sbin contains binary files for system administrators. If you can’t find a system binary under /sbin, look under /usr/sbin. For example: atd, cron, sshd, useradd, userdel
• /usr/lib contains libraries for /usr/bin and /usr/sbin
• /usr/local contains users programs that you install from source. For example, when you install apache from source, it goes under /usr/local/apache2

10. /home – Home Directories

• Home directories for all users to store their personal files.
• For example: /home/john, /home/nikita

11. /boot – Boot Loader Files

• Contains boot loader related files.
• Kernel initrd, vmlinux, grub files are located under /boot
• For example: initrd.img-2.6.32-24-generic, vmlinuz-2.6.32-24-generic

12. /lib – System Libraries

• Contains library files that supports the binaries located under /bin and /sbin
• Library filenames are either ld* or lib*.so.*
• For example: ld-2.11.1.so, libncurses.so.5.7

13. /opt – Optional add-on Applications

• opt stands for optional.
• Contains add-on applications from individual vendors.
• add-on applications should be installed under either /opt/ or /opt/ sub-directory.

14. /mnt – Mount Directory

• Temporary mount directory where sysadmins can mount filesystems.

15. /media – Removable Media Devices

• Temporary mount directory for removable devices.
• For examples, /media/cdrom for CD-ROM; /media/floppy for floppy drives; /media/cdrecorder for CD writer

16. /srv – Service Data

• srv stands for service.
• Contains server specific services related data.
• For example, /srv/cvs contains CVS related data.

How to Run a C program/Shell script with root privilege

This method for creating a script that runs as root automatically.

1. Open a text editor, and type up your script:

   #!/bin/sh
   program1
   program2
   ...

2. Save the file as something.sh.
3. Open a terminal, and enter the following commands:

   $ su
   [enter password]
   chown root:root something.sh
   chmod 4755 something.sh
   exit
   

4. Then, finally run it with ./something.sh, and it'll have root access!

...or not. Most likely, you'll get the same error messages that you did before you ran those commands. If your script does actually work,
Take the down part for executing it.

The problem The instructions are fairly straightforward. Create the shell script that you want to execute, and change the owner and group to root (chown root:root). Now comes the command that's supposed to do the magic:

chmod 4755

Except it doesn't. Well, the truth is actually that the setuid bit is disabled on a lot of *nix implementations due the massive security holes it incurs. If the method originally mentioned doesn't work for you, chances are that your Linux distribution has disabled setuid for shell scripts.

The solution(s) One way of solving this problem is to call the shell script from a program that can use the setuid bit. For example, here is how you would accomplish this in a C program:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

int main()
{
   setuid( 0 );
   system( "/path/to/script.sh" );

   return 0;
}

chown root:root runscript
chmod 4755 runscript

Now, you should be able to run it, and you'll see your script being executed with root permissions.
Conclusion With all that said, running shell scripts with setuid isn't very safe, and the distro designers had a pretty good idea of what they were doing when many of them disabled it. If you're running a multiuser Unix environment and security is an asset for you, make sure that your scripts are secure. A single slip can result in the compromising of an entire network. Only use them when absolutely necessary, and make sure you know exactly what you're doing if you do decide to use them.