File permissions are not only paramount to the security of your data, but are a fundamental necessity of any UNIX file system. Their entries advise the kernel who can and cannot access the data. To fully understand the concept of what file permissions are and the need for their existence, one must take a look at the UNIX operating system itself.

The UNIX operating system was designed to maintain and deliver data securely in a multi-user/client-server environment. One of the major characterizations of UNIX is its hierarchical file system. Among other unique features, the file system contains a series of tables known as INODE tables. These tables are really indexed arrays containing all necessary information to access a file such as its location, attributes, and permissions. Maintained by the UNIX kernel, the INODE table makes the UNIX file system is a robust and unique platform for the sharing and maintenance of information.

What are file permissions and why are they important?

A permission is an attribute tied to a file in the INODE table that states who can do what to a file. When a file is created, the UNIX kernel associates the file with a 'user' and a 'group'. Commonly, the user/group which owns the process creating a file will be assigned as the files initial owner. An example of permissions assigned to a list of files would be:

webuser@hostname:~/Desktop$ ls -al ./
drwxr-xr-x  2 webuser webgroup      4096 2009-01-06 21:44  Pictures
drwxr-xr-x  2 webuser webgroup      4096 2009-01-06 21:44  Templates
-rw-r--r--  1 webuser webgroup 166329665 2009-01-08 15:37  dd_doubleup_1.mp3
-rw-r--r--  1 webuser webgroup  74083403 2009-01-08 14:47  dd_equator_2.mp3

Notice the command [ ls -al ]. 'ls' is a UNIX command designed to 'list segments'. While there are many flags and behaviors you can associate with ls, at its core, it is designed to query the INODE table and retrieve a list of files with their associated attributes and permissions.

You will notice several sections of data returned. The first section ( drwxr-xr-x ) contains the file type, permissions and its sticky bit.

File Type Bit

The file type is represented by the first bit.

     File Type                Permissions    File Path
 -   Regular File             -rw-------     /home/werd/.bash_history
 d   Directory                drwxr-xr-x     /home/webuser
 b   Block Special File       brw-rw----     /dev/sda1
 c   Character Special File   crw-rw----     /dev/watchdog
 l   Symbolic Link            lrwxrwxrwx     /cdrom -> /mnt/cdrom
 p   Named Pipe               prw-r-----     /dev/xconsole
 s   Domain Socket            srw-rw-rw-     /dev/log

Permission Bits

The next nine bits represent the permissions assigned to the file. These nine bits are divided into three classes: owner class, group class, and other users class. Each bit represents the action each class of users can and cannot take.

  drwxr-xr-x  2 webuser webgroup      4096 2009-01-13 00:19 Pictures
  ( rwx ) ( r-x ) ( r-x ) = ( owner ) ( group ) ( other )

This particular set of permissions states the owner (webuser) can read, write, and execute (cd into) this directory. All members of the group (webgroup) can read and execute, but not write to this directory. All members not the owner or in the group (webgroup) can read and execute, but not write to this directory.

Permissions on a regular file
 (w) = File is writable to the class of user
 (x) = File is executable to the class of user
 (r) = File is readable to the class of user
Permissions on a directory
 (w) = Directory can be written to by the class of user
 (x) = Scripts contained inside can be executed by the class of a user
 (r) = Directory contents can be read by the class of user

Special Bits and Their Uses (SUID,SGID,Sticky)

In addition to (rwx), there are three other special permission bits which can be set. The Set User ID (SUID) and Set Group ID bits (SGID) are represented as (s) or (S) depending whether the file is executable. The bit SUID and SGID bits tell the kernel on execution which user the process will be owned by when the file is executed. When a file is executed with a SUID or GUID bit, regardless of what user initiated the process, it will have the security access of the SUID and GUID bits.

  -rwsr-xr--   1 root     dip        277160 Nov 20 14:58 pppd
  drwxrwsr-x   2 libuuid  libuuid      4096 Oct 29 17:53 /var/lib/libuuid
  -rwsr-sr-x   1 libuuid  libuuid     13796 Oct 13 08:09 /usr/sbin/uuidd

When the process ( /usr/sbin/uuidd ) is launched, the kernel assigns the process with the owner of ( libuuid ) and ( libuuid ) on execution. The user launching the process will have no hand in the permission of any files created by this process as it is assigned ( libuuid.libuuid ). Example:

  webuser@hostname:~/Desktop$ /usr/sbin/uuidd &
  [1] 29265
  webuser@hostname:~/Desktop$ ps faux | grep uuid
  libuuid  29266  0.0  0.0   2072   308 ?        Ss   16:39   0:00 /usr/sbin/uuidd

For reasons more complex than we need to explain in this article, the process ended immediately and forked using the new UID/GID immediately after the initial thread creation. You will notice the new ownership of the process is now ( libuuid ) instead of ( webuser ) as expected. For more information on SUID/GUID process execution; there are ample articles on the Internet, and quite possibly one here soon!

The third bit and last column is the sticky-bit. This feature has very limited use in today'as UNIX environments. Originally, this bit was used with executables and instructed the operating system to retain the execution instructions in swap-space to speed up future execution. As UNIX was designed to be a multi-user environment, the idea for commonly used applications to maintain its own memory space, loading the instructions directly from memory provides speed and stability.

The second and most common use of the sticky-bit in today's UNIX environments is to establish a set of permissions for a folder telling the kernel who can and cannot modify files. When a directory has files created by multiple users, the sticky-bit states that only two users may delete a file within. These two users are the files true owner and root. The most common place you will find this bit is on the /tmp/ directory.

Bits and their Octal representation.

You will commonly see permissions represented in the form of (0777) or (0755) or (0644) etc. This is the octal representation of a file permission. Each column represents the three classes of users mentioned earlier. The first column is the owner, second is the group, and third is other users. Each number represents a combination of permissions.

In their octal form, permissions are as follows:

  Perm               Octal Value
  (r) Read           4
  (w) Write          2
  (x) Execute        1
  (rw)               4 + 2 = 6
  (rx)               4 + 1 = 5
  (wx)               2 + 1 = 3
  (rwx)(rwx)(rwx)    0777
  (r-x)(---)(---)    0500
  (rw-)(r--)(r--)    0644

The octal representation of a set of permissions is really the individual permissions added together to create the three classes of users and how they can access the files. This provides a quick and efficient way to modify permissions and describe the permissions. Instead of saying, folder Pictures has read and write and execute for the owner, read and execute for the group, read and execute for all other users, you can simply say: The folder Pictures is set to 755.

So how are SUID/GUID/Sticky bits represented in Octal Form? The first digit used to reference these special bits. Example:

  Perm         Octal Value
  SUID         4000
  GUID         2000
  Sticky Bit   1000
  rwSrwxrwx    4777
  rw-r-sr--    2644
  rwxrwxrwt    1777

Conclusion & References

File permissions are essential for the UNIX kernel to interpret who can access a file and how the file should be handled when it is accessed. I have included links below to help gain a deeper perspective on the subject.

-- There are no references for this article.

Comments