Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)

Introduction to Unix permissions model

Understanding file permissions on Unix

News Access Control in Operating Systems Recommended Links SUID/SGID attributes Sticky attribute (sticky bit) in Unix Setgid bit in directories umask
World writable files problem SUID/SGID Checkers File Permissions Hardening Groups administration Admin Horror Stories Humor Etc


Unix borrowed from CTSS a simple model of file permissions and somewhat extended it. This model which is called Classic Unix Permissions models has proven to be amazingly effective, flexible and easy to understand. All those three signs of great design are present in it. And in retrospect it proved to be not that simple. But it is still within intellectual capabilities of most Unix sysadmins. And that's a great achievements as many alternatives and extensions are not. For example, recently, there was an attempt to extend Classics Unix permission system  using ACLs to compensate for its fundamental weakness: file can belong only to a single group. ACL model is similar to approach to file permissions that is used in Windows  but it is so complex, that very few organization have adopted this approach on Unix servers belong some trivial cases of exported via Samba or NFS filesystems.  And very few sysadmins understand it, and even those who understand vary of using it. This lack of adoption had shown critical importance of complexity in operating system permission model. Also the existence of two models in Unix is an additional (and huge) negative factor which not only confuse administrators and represent a serious security risk.  The effect quite opposite of intention. As in the saying "roads to hell are paved with good intentions." 

In the original Unix model, each file has just three access categories of user: User (u), Group (g) and Other (o). Group is essentially a role and primary group is a primary role for a particular user. Any user can be a member of any number of groups, but unfortunately groups can't contain other groups.  So all groups in Unix are "prime groups" consisting of users. In my view this is the most serious blunder of the Classic Unix model. Of course you can "precompile" /etc/group file creating the ability to use other groups as members of groups via backdoor . This way you can introduce "metagroups" -- groups that are aggregations of existing groups and users, not only users as in "prime groups". But that solution  requires additional efforts and discipline (in this case /etc/group need to be automatically generated from some template with macros).  If we assume that the number of group allowed is large (approximately the same as the number of files/directories) metagroup approach is as powerful as ACL model and is much simpler.  It requires relatively simple modification of the /etc/group file.

There is also auxiliary concept of  system groups which is similar to the concept of privileged ports. For example, all groups with GID below 100 are often considered to be system groups.  System groups has special properties, and designed mainly for partitioning of permission space. For example, most users which have system group as primary group have no legitimate shell (/bin/noshell or /bin/false is used instead; the former logs in access attempts), so nobody can login as such a user.  In other words the numeric value of group partition groups into two categories with lower value groups considered to be more privileged. Again this is a similar idea to the idea of privileged ports and despite its simplicity is quite powerful and permits additional checks via PAM mechanism that increase security.  One such privileged group is called wheel and it can be used to limit the ability of users to switch to root, independently whether they know root password or not.  This idea of wheel group like many brilliant ideas came from BSD.

One pretty recent interesting extension of Classic Unix model is the concept of  User Private Groups (UPG) introduced in Red Hat.   This is simply a new convention for assigning primary groups to real (human) users. Whenever you create a new user, by default, he or she has a unique group that has GUD equal to UID.  UPG scheme makes UNIX groups easier to use and make home directories more secure. This is just a procedural enhancement, which does not add or change anything in the standard UNIX way of handling groups.

Unix file permission structure

Now let's return to Unix file permission structure. In Unix each file has three attributes for each of three access categories (owner, group and world):

There is also on implicit attribute: the ability to delete file/directory. It is property not a file/directory in question,  but the directory in which it contained.  It the user has write access to the directory he/she can delete any file in it.

One of  limitations of the Unix model is that ordinary users do not have the right to make their own groups. In this way, the model shoots itself in the foot. There are ways around this, but Unix has not introduced a standard solution to the problem. We can think of the Unix model as being a coarse approximation to the model of ACLs.

Inheritance of permissions

Every user on a Unix system has a unique username, and is a member of at least one group (the primary group for that user). This group information is held in the password file (/etc/passwd). A user can also be a member of one or more other groups. The auxiliary group information is held in the file /etc/group. Only the root user can create new groups or add/delete group members.

One of the most interesting aspects of file security is the matter of what security attributes are inherited by new files. Files have to start out with some set of permissions.

In Unix the scheme for assigning a new file permission  is a Unix flavor dependent matter. In the list below, you should note that there are almost no pure BSD/SysV systems left. Most systems are hybrid.

Every directory and file on the system has an owner, and also an associated group. It also has a set of permission flags which specify separate read, write and execute permissions for the 'user' (owner), 'group', and 'other' (everyone else with an account on the computer). 

  1. Owner  The file's owner. You can specify read, write execute permission and one additional attribute for files:
  2. Group  Users who are in the file's group. You can specify read, write execute permission and one additional attribute for directories:
  3. Other  Everybody else on the system (except the superuser)

    The 'ls' command shows the permissions as well as owner and the group associated with file(s) when used with the -l option. 

All three groups of permissions for a given file consist of three separately granted rights:

In ls listing each specification of permissions for the particular file is usually  called "file mode" and it occupies 7 bytes, Here are two examples of file mode:


The first character of the file's mode field indicates the type of file:




Plain file




Solaris door construct


Character device (tty or printer)


Block device (usually disk or CD-ROM)


Symbolic link (BSD or SVR4)


Socket (BSD or SVR4)

= or p

FIFO (System V, Linux)

The next nine characters are actually three groups of three character each and indicate read, write, and execute permissions for owner, group and "the world" or "others":






Read access means exactly that: you can open a file with the open( ) system call and you can read its contents with read( ).



Write access means that you can overwrite the file with a new one or modify its contents. It also means that you can use write( ) to make the file longer, or truncate( ) or ftruncate( ) to make the file shorter.



If a file's execute bits are set, you can run it by typing its pathname (or by running it with one of the family of exec( ) system calls). How the program is executed depends on the first two bytes of the file.

The first two bytes of an executable file are assumed to be a magic number indicating the nature of the file. Some numbers mean that the file is a certain kind of machine code file. The special two-byte sequence "#!" means that it is an executable script of some kind (the remainder of the first line specifies the program that should execute the script). Anything with an unknown value is assumed to be a shell script and is executed accordingly.

File permissions apply to devices, named sockets, and FIFOs exactly as they do for regular files. If you have write access, you can write information to the file or other object; if you have read access, you can read from it; and if you don't have either access, you're out of luck.

File permissions do not apply to symbolic links. Whether you can read the contents of a file pointed to by a symbolic link depends on that file's permissions, not the link's. In fact, symbolic links are almost always created with a file permission of "rwxrwxrwx" (or mode 0777). These file permissions are then ignored by the operating system.

Note the following facts about file permissions:

On Solaris systems, there may be an additional character following the permission characters:

-rwx--x--x+ 3 spaf spaf 24219 May 17 00:52 example

The +  symbol indicates that this file (or other item) has an ACL associated with it. An Access Control List (ACL) provides a more comprehensive set of permissions on the file than can be described with the single user/single group model.

Because file permissions determine who can read and modify the information stored in your files, they are your primary method for protecting the data that you store on your Unix system.

Most people think that file permissions are pretty basic stuff. Nevertheless, many Unix systems have had security breaches because their file permissions are not properly set, and several provide automated tools for checking the permissions of important system files on a regular basis.

Directory permissions

Unix stores the contents of directories in nodes that are similar to the nodes used for regular files, but they are specially marked so that they can be modified only by the operating system.

As with other files, directories have a full complement of security attributes: owner, group, and permission bits. But because directories are interpreted in a special way by the filesystem, the permission bits have special meanings






You can use the opendir( ) and readdir( ) functions (or the ls command) to find out which files are in the directory.



You can add, rename, or remove entries in that directory.



You can stat the contents of a directory (e.g., you can determine the owners and the lengths of the files in the directory). You also need execute access to a directory to make that directory your current directory or to open files inside the directory (or in any of the directory's subdirectories).

If you want to prevent other users from reading the contents of your files, you have two choices:

Note the following:

Novice users often encounter irritating "Permission denied" message. And some of them quickly learn that using root or setting permissions to 777 resolve this problem ;-).  That teach us important lesson that educating the users probably can help avoiding a lot of security problems. But Unix permissions while simple of the surface actually are not that simple and can create problems not only for naive users but for system administrators as well. We will not discuss what are alternative and limit yourself to the basic unix permission scheme here.

As we all know Unix files have three types of owners: user, group, and others (world).  For each type of owner there are three types of permissions: read (r), write (w), and execute (x).  Directories are actually a special kind of files as as such have the same structure of permissions but their meaning is not identical and the directory permissions affect the permissions on the files in this directory but not vise versa.

There also also three "special" permissions that are not bound to a particular owner (suid, sgid and sticky bit). 

In most cases the root user is not a subject to any permissions restrictions.

How-To Hardening Systems, Users, Groups and Security

On other systems the group owner of su should be changed to wheel, or root on some systems, or security on AIX. Members of this group should be restricted to those who are given and authorized to use the root password. Su is left group executable but world execution rights are removed. This prevents anyone who is not authorized to use the root password, from using it under most circumstances, even if they learn the root password. Most server consoles are in secure areas where non technical staff do not have access or are very conspicuous. On systems that do not allow direct root access from remote locations, it not only takes two passwords to gain root privileges but they have to be the right two passwords. The first password is reduced from the entire user population to a very small population that hopefully pick good passwords.

The technique might be extended to other programs though none have quite the security implications of su.  I would never set the SUID bit on a program that did not have it and then restrict the use of that program to wheel. Rather the members of wheel should su or sudo to access the program. Where the technique may make sense is if there are programs that are already SUID and it is believed that the functions provided by these programs are not needed by ordinary users. Presumably the system authors thought world execute access is not particularly harmful or the program would not be set up in such a way. Removing world access and changing the group owner to wheel restricts access to the program while keeping it convenient for wheel members. To make such programs secure, the SUID bit should be reset, forcing wheel members to su or sudo to use the command.

All directories have the same permissions structure as files (owner/group/world) with three permissions for each group. BTW that includes / (root) directory. Here is how to view them:

ls -ld /

note that you can see the number of 512-byte blocks used by the directory (the size of the directory)

Many Unix administrators do not suspect that classic ls -la command that is used to list "dotfiles" also produces the permissions of the current directory and its parent: 

When a user creates a directory its permissions are determined by the current umask.  It's owner corresponds to the effective UID of the account that create the directory, but its group depends on the directory permissions in which file is created. If sticky bit is set of the current directory then the group will be inherited from the current directory. Otherwise the primary group of the account will be used.

When user copies directory its ownership is changed to the user uid and the group is preserved only if the user is a member of this group.

Setgid bit in directories  has a special meaning in BSD Unix, and this behavior is now emulated by Solaris and most other commercial and free Unixes. When a directory has setgid on, files written by a user in that directory will have the same group owner as the directory, rather than the primary group of the user.  In this case  writable directories that belong to any system group are very dangerous (you can set sgid bit on the directory and create a file that will be owned by a group  and generally it should not be used with world writable directories. 

Sticky attribute (sticky bit)  controls the ability to delete file that do not belong to an owner in writable directories. It's another BSD-derived idea that became a standard feature in Unix. If it is set then only the owner of the file, owner of the directory and root can delete files. Please note that the owner of the file/directory can set/remove any permissions for the file including suid, sgid and sticky bit. Unix directory access permissions say that if a user belongs to a group that has write permission on a directory or the directory is world-writable, he/she can rename or remove files there; even files that has a different owner. Most modern Unixes implement BSD-derived idea of a sticky bit that can block this behavior.  When the sticky bit (t) is turned on for a directory users can have read and/or write permissions for that directory, but they can only remove or rename files that they own. The only people who can rename or remove any file in that directory are the file's owner, the directory's owner, and the superuser.

The /tmp  directory in Solaris by default has a sticky bit set. For example executing a command "ls -l /tmp" will produce the following output: :

Note that it is normally owned by the user sys. Here's another typical example of sticky bit usage: the user skeptic makes a world-writable directory and sets the sticky bit (shown as t here) to share files with members of the group staff:

% mkdir home/groups/perlsctipts
% chmod 1775 perl_scripts
% ls -ld perl_scripts % chown :staff perl_scripts
drwxrwxrwt   2 skeptic    staff           32 Nov 19 10:31 share

Now members of the group staff can create files in it, but they cannot delete files owned by other people. When  Bill tries to remove a file that belongs to Alice, he can't:

% ls -l
total 2
-rw-r--r--   1 alice    staff          0 Nov 19 11:32
-rw-r--r--   1 bill     staff         0 Nov 19 15:34
-rw-r--r--   1 carol    staff         0 Nov 20 12:29
jennifer% rm data.ellie
data.ellie: 644 mode ? y
rm: data.ellie not removed.
Permission denied

The sticky bit got its name on early Unix systems in the days before demand-paged virtual memory. If the sticky bit of an executable file was set, after the program exited a copy of its text segment was saved in the system's swap area, i.e., it would ``stick around'' for the next use. This feature was used to make frequently-run programs load a little bit faster. This meaning of the sticky bit is no longer particularly relevant.

Although it is not a part of the POSIX specification, most System V and Berkeley Unix systems defined a new meaning for the sticky bit. If a directory's sticky bit is set, a file in the directory may be deleted only by the file's owner, by the directory's owner, or by root.

This provides an additional measure of security for directories that are shared by several users, for example /tmp:

$ ls -ld /tmp
drwxrwxrwt  3 root   root   1024 Jan  1 09:49 /tmp
$ ls -l /tmp
-rw-------  1 roman  users     0 Jan  1 09:49 bar
-rw-------  1 root   root      0 Jan  1 09:47 foo
$ rm /tmp/bar
$ rm /tmp/foo
rm: /tmp/foo: Operation not permitted

Without the sticky bit, I would have been able to remove root's file from /tmp.

The concept of trusted path

Consider this scenario:  You are the administrator of a multi-user server.  All of a sudden there is a new bug in the Pentium(tm) processor! As it happens, this bug causes the CPU to lock up entirely, requiring a cold reboot.  This bug is also exploitable by any user regardless of privilege.  All it necessitates is for the malevolent user to 1) get the source, 2) compile the exploit, and 3) execute the program.

You cannot prevent anyone from getting this exploit.  It's out there.  You could remove executable permissions from the compiler on your machine or remove the compiler entirely, but this does not stop the user from compiling the exploit elsewhere, and getting the binary on your machine somehow. 

However, if you only allow binaries to be executed from a trusted path, you can block users from executing this exploit.  A trusted path can be defined as one that is limited to root owned directories that are not group or world  writable.  /bin, /usr/bin, /usr/local/bin, are (under normal circumstances) considered trusted. 

Any non-root users home directory is not trusted, nor is /tmp.  Such configuration can be a major annoyance to users who like to execute code and scripts from their home directories!  And it will make you extremely un-popular as far as these people are concerned.  But at the same time for critical servers it will also let you sleep easier at night knowing that no unscrupulous persons will be executing malicious bits of code on your machine.

The implementation is very simple: before any call to exec is allowed to run, we open the inode of the directory that the executable lives in and check ownership and permissions. If the directory is not owned by root, or is writable by group or world, we consider it untrusted.

Ownership issues on directories

When a non-root user copies directory its ownership is changed to the user uid and the group is preserved only if the user is a member of this group.

User can change group only to those groups where this user is a member.  If user copies the file then ownership of the file is changes to the user. Group is preserved (with -p option) if and only if the user is a member of the original group. 

What you can do with file is actually determined not only permissions of the file itself, but also permissions of the directory in which the file is located. Actually in Unix effective write attribute for the file is partially (delete operation) inherited from the corresponding attribute of the directory,  for example:

ls -la /.profile
-rw-r--r-- 1 root wheel 658 Jul 26 23:14 /.profile

This looks counterintuitive, but that's how Unix operate: any writable by group or world directory in Unix permit file deletion renaming and creation by any member of the group or if it's world writable by the world (deletion can be blocked with sticky bit, but renaming and creation are not).

As such world writable directories are very dangerous and definitely represent a security risk.

Symbolic mode of chmod

Most Unix administrators that I know are pretty comfortable with octal permissions, but rarely use chmod in symbolic mode. The syntax for symbolic mode actually is simpler and more logical then octal mode:

who operator permission filename

where who can be:

and operator can be:

and the permissions can be r, w, x, s, t, and X. Note that there is no capital S; if you want to keep the execute bit when you set the SUID or SGID bits, use both s and x. If you want to set the SUID bit, use s with a who of u; to set the SGID bit, use s with a who of g. To set the sticky bit, use t with a who of o.

Let's try to change the foolowing file:

-rw-r--r-- 1 skeptic wheel 0 Aug 19 11:27 test

and want to end up with:

-rwsr-xr-x 1 skeptic wheel 0 Aug 19 11:27 test

so let's try this:

chmod -v a+sx test
ls -la test

 -rwsr-sr-x 1 skeptic wheel 0 Aug 19 13:05 test

Close, but no cigar. Since we specified a who of a (or everyone), we set both the SUID and SGID bits. Let's try again:

rm test
touch test
chmod u+s go+x test

 chmod: go+x: No such file or directory

We got a syntax error on that command because chmod expects the who, operator, and permissions to be a string of characters without any spaces. Whatever follows the space is interpreted as the name of the file whose permissions are being set. Let's try again:

chmod -v u+s,go+x test
ls -la test

 -rwSr-xr-x 1 skeptic wheel 0 Aug 19 13:16 test

Almost there; we seem to have set the SUID bit and given everyone except the owner execute permission. One more try:

rm test
touch test
chmod u+sx,go+x test
ls -la test

 -rwsr-xr-x 1 skeptic wheel 0 Aug 19 13:22 test

Success. You can see that it is a good idea to always doublecheck your permissions using ls -la after using the chmod command to make sure you actually set the permissions you intended.

See also



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2016 by Dr. Nikolai Bezroukov. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: September 12, 2017