Introduction to Unix permissions model

Understanding file permissions on Unix

• Introduction
• Setting file permissions using symbolic notation
• Disabling Unix permission model
• Unix file permission structure
  • Groups in Unix are atomic but you can use metagroups by writing a compiler script
  • Special users
  • Special groups: wheel and system groups
• SUID vs SGID vs Sticky Bit
• Inheritance of permissions, umask
• User private groups
• File permissions do not apply to symbolic links
• Interpretation of ls -l listing
• The order of interpretation of permissions
• Directory permissions
• The concept of trusted path
• Ownership issues on directories
• Symbolic mode of chmod
• See also

Introduction

Unix borrowed from CTSS a simple model of file permissions and somewhat extended it. This model which is called "Classic Unix Permissions Model." It has proven to be amazingly effective, flexible and relatively 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. That's a great achievements, the level far above many alternatives and extensions. It does possesses conceptual integrity (the sign of high level of architectural design) and survived the test of the time.

Because file permissions determine who can read and modify the information stored in the files in the particular Linux system, they are the primary method for protecting the data.

Relatively recently it was extended with ACLs to compensate for some of 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. So instead of useful addition ACL became the major security threat. Very few sysadmins understand it, and that create vast open space for hackers who have time and desire to study them for months or even years for creating backdoors. The is classic "the road to hell is paved with good intentions" situation, which had shown critical importance of complexity in operating system permission model: the existence of two models in Unix is an additional (and huge) security risk.  The effect quite opposite of intentions.  That means that all files with ACLs on important server should be regularly audited for unauthorized changes of those permissions.  For the same reason ACL is generally a bad idea for SUID-root files (see below).  Sudo is a safer path to allow additional users to execute them.

Most people think that file permissions are pretty easy stuff. That's not true. On large system even simple staff become mind-bogglingly complex. Many linux  servers systems have had security breaches because their file permissions were not properly set, or were changed for "easy" access. There are several automated tools which help with checking the permissions of important system files and directories. Typically they are part of so called hardening packages. That should be done on regular basis.

Classic Unix model specified thee group of permission -- user(owner, group and other (everbody else). All three groups of permissions for a given file in turn consist of three separately granted rights:

• r -- Permission to read  For directories this mean the ability to obtain he listing of directories
• w  -- Permission to write. For directories that means the ability to change attributed of the file, delete files and create an new files.
• x -- Permission to execute. For directories this attributed has special meaning: it means the ability to access files in the directory. For example you can't cd to the directory if for you this attributed is not granted. 

File permissions also 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

Each permission is encoded by one bot. So it takes 9 bits to specify all permission. They are often listed in octal notation. For example 777 means that all permissions are granted 000 -- means that none is granted.  The decoding is simple:

Note the following important two facts about file permissions:

• You can have execute access without having read access. In such a case, the program can be run by a person without giving them permission to read the contents of the file or make a copy of the program. This ability is useful in case you wish to hide the program for analysis, but there are ways to circumvent the protection and you can depend on this protection as a defense from sophisticated hackers.
   
• If you have read access but not execute access, you still can copy the file, assign  execution permissions to it run as yourself (but not the original owner). The copy will be different in three important ways:
  1. It will have a different absolute pathname,
  2. It will be owned by you, rather than by the original program's owner.
  3. It will not have SUID bit set.

This behaviour is very important for files that have SUID bit  set as copying such file to your home directory is common way to obtain a backdoor to the  system (the typical unauthorized file with SUID set that is often copied to obtain a backdoor to the system is shell; the third rule means that you can do it only as root, so you need to obtain unauthorized root access first to perform this trick).

But there is an interesting  nuance here -- if file has SUID and owner is set to root, copying of the file by any user who is not root lead to both the loss of  SUID bit the loss of ownership of the file by the root.  So in even very simple and straightforward model has tricky "use cases."  That suggest that ACL, a "bolted on" windows style permission system which are much more complex, is a real swamp which can consume even reasonably talented sysadmins with ease.

Disabling Unix permission model

While simple and effective Unix permission model is still above the head of many people, especially if many groups are involved in the project.  Quick fix used is suhc situation is to set permission to 777, which means disabling any access control. This is definitely a very bad solution, and in no way it can be recommended in any circumstances. This sad reality is actually pretty typical for some large US corporations, especially their research arms.  Attempts to fix this situation required pretty high level of understanding what Unix permission model is about and how it operated, because of the level of user resistance.

Unix file permission structure

In Unix each file has three categories of access plus modifiers for this access in a form of special attributes:

• The user (the owner) -- the single entity (account) who own the file or directory. Multiple owners are not permitted. Along with real human accounts there are also system accounts (such  as root) and application accounts (such as apache, postfix, etc).
• The group -- this is essentially a role which defines who should have access to this file or directory. Groups in Linux are atomic and can consist only other users, not groups. There are also system groups (such as root, sys, wheel, etc) and "traditional" groups such as users and operators.
• The other (or world) -- everybody else
• Modifiers of the access. Contains three special attributes
  • SUID -- typically used for files owned by root and allow dinamically switch UID of the process to root even if envoked by non-proviledged user
  • SGID --  Allot to inherit the group for newly created form from th egroup to which the directoy that contian this fiule belongs, not the user primary group.
  • Sticky bit -- typically used for directories and allow to clock the aboility of users other then tthe owner to delete files (ability to delete file in Unix is defined in the directory that contian file, not the file itself, contaraty to view of many users and sysadmins.

The are also three attributes for each of three access categories (owner, group and world):

• Read Permission to read. Read access means that you can open a file using the open( ) system call
• Write Permission to write. Write access means that you can overwrite the file with a new one, or modify its contents.
• Execute.  Permission to execute as a program. Since executing a directory as a program is a meaningless operation, the execute-permission bit, for directories, is redefined to mean permission to access inodes of entries of the directory for all filenames that are contined in the directory;
  • If a directory has read permission but no execute permission for a given user, user may list the names of the directory with ls, but can't list any attributes of those files, execute them or perom any other operation on them.
  • If a directory has execute permission but nor read permission for a given user, he/she can execute program in it, if he/she knows its name. Also can list the file attributes and perform any other operation on it. But he/she can't obtain the listing of the directory. He also can access files with known names in the directory, but may not read attributes of the file contains in the inode (size, owner, group). Write permission on a directory is interpreted to mean that the user may create and delete files in that directory; it is impossible for any user to write directly into any directory. 
  • If a file's execute bits are set, you can run it by typing its pathname (or by running via 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 a script and that the remainder of the first line specifies the program that should interpret the script. Anything with an unknown value is assumed to be a shell script and is interpreted by the default shell.

The execution bit on the directory not set, this essentially works as partial access control for files in this directory: there  is no way to obtain a listing of the directory although if you know file name you can access and execute the file.

It is important to understand that the ability to delete file/directory normally is a property not of 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. this behaviour can be changes by marking the directory with sticky bit (typically /tmp) is marked with sticky bit) which blocks the ability of users other then owner of the file to delete file, this substituting the owner defined by the  directory with the owner defined by the file.  

One of  limitations of the Unix model is that ordinary users do not have the right to make their own groups, because the groups does not have the notion of owner and it is impossible to distinguish which groups were created by the root and which by the user. So if the user wants to grant access to particular file to people outside the groups that exist on the system, he/she can only grant access to everybody via "world" set of permissions. This is where Classic Unix permission model shoots itself in the foot. There are ways around this, but Unix has not introduced a standard solution to the problem. Yet.

So you can see that even simple and elegant solution such classic Unix permission model has some tricky issues and at retrospect does not looks such a simple concept as initially.  As always the devil is in the details. 

Permission are normally changed using chmod command and octal notation for them is dominant.

Setting file permission using symbolic notation

Normally sysadmin sets file permission using octal notation. But sometime is it more convenient to use symbolic notation.  This is the case, for example, when you want to change only one permission in the group and do not touch any other, leaving them "as-is". For example you might wish to remove write permission form file. 

When chmod command is invoked using symbolic notation, it will modify or set the flags as specified by the maskExpression with the syntax

[user-class-letters] operator permission-symbols

Multiple maskExpressions are separated by commas.

A space terminates the maskExpression (s).

• The permissions are applied to different user classes:

• The operator specifies how the permission modes of the mask should be adjusted.

• The permission-symbols indicate which file permission settings are to be allowed or prohibited by the mask.

For example:

chmod u-w ~.bash_profile

Groups in Unix are atomic but you can use metagroups by writing a compiler script

To understand this model we need to understand notion of UID (user id) and GID (group id). Both are integers with minimal equal 0 and  which max set to a certain (but very high) value. I think 64 bit integers are now used for both.  Rood has UID 0. There is also group root which has GID 0.  File with UID 0, GID 0 are typically the most protected class of files in Unix.

In the original Unix model, each file there are three types of access permission: User (u), Group (g) and Other (o). Group is essentially a label for the role and defines a set of user that should have access to particular file (which is a definition of role). This way we can talk about such roles of webmaster (who needs to have access to LAMP stack -- Apache, MySQL and PHP), data base administrator (who need to have access to particular set of databases used on the server, for example MySQL and Oracle). Programmer is also a role and he/she needs access to compilers, scripting languages, make utility, and such. In real organizations those groups can intersect and that creates major problems with classic Unix permission model as any in this model group is atomic -- can consist only of individual users, not the other groups.   

In other words, 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 "atomic" consisting of only users. This is a well known weakness of the Classic Unix Permissions Model. Of course, you can "precompile" /etc/group file creating the ability to use other groups as members of groups via special script which explains then to list of users. This way you can introduce "metagroups" -- groups that are aggregations of existing groups and users. 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, then this metagroup approach is as powerful as ACL model and is much simpler.  It requires relatively simple modification of the /etc/group file.

Special users

Unix essentially ha only one special user -- superuser or root.  Some flavor of Unix like Solaris have more flexible subsystem called RBAC (role based access control), but in Linux this is not the case.

Special groups: wheel and system groups

There is also auxiliary concept of  system groups which is similar to the concept of privileged ports. We can attach special privileges to such groups.  It is also possible to assign special meaning to certain integer intervals for the purpose of auditing of system activity. 

For example, all groups with GID below 100 are often considered to be system groups and files which are owned  by those users are considered system files (Unix does not have system attributed like Windows, but this rule can compensate for this shortcoming).  You can enforce special rules for deletion of  such files, using some king of wrappers over system command like rm. This is important because wiping out of the system due to Creative uses of rm is major problem that each Linux sysadmin sooner or later faces (see  Sysadmin Horror Stories )

By default RHEL7 contains around 50 system groups:

root:x:0:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mem:x:8:
kmem:x:9:
wheel:x:10: 
cdrom:x:11:
man:x:15:
dialout:x:18:
floppy:x:19:
games:x:20:
tape:x:30:
video:x:39:
lock:x:54:
audio:x:63:
users:x:100:
utmp:x:22:
utempter:x:35:
ssh_keys:x:999:
input:x:998:
systemd-journal:x:190:
systemd-bus-proxy:x:997:
systemd-network:x:192:
dbus:x:81:
polkitd:x:996:
libstoragemgmt:x:995:
printadmin:x:993:
abrt:x:173:
tss:x:59:
dip:x:40:

That's way too  many. Among them are groups that have GID above 100 .

ssh_keys:x:999:
input:x:998:
systemd-journal:x:190:
systemd-bus-proxy:x:997:
systemd-network:x:192:
dbus:x:81:
polkitd:x:996:
libstoragemgmt:x:995:
printadmin:x:993:
abrt:x:173:

Some groups an be classified as applications accounts for system daemons although the boundary is really fuzzy here:

slocate:x:21:
rpc:x:32:
apache:x:48:
sshd:x:74:
postdrop:x:90:
postfix:x:89:
ntp:x:38:
chrony:x:994:
tcpdump:x:72:
screen:x:84:

Some system groups were introduced mainly for partitioning of permission space: groups as root, sys, adm, bin, daemon, etc do not have any members and they have no legitimate shell ( /bin/noshell or /bin/false is used instead in /etc/passwd), so nobody can login as such a user.

In other words the numeric value of group is used in Linux  and other flavors of Unix to partition groups into two categories with lower value groups considered to be system groups. This is a compensation for missing "system" attribute in files.

The idea of system group is somewhat similar to the idea to the idea of privileged ports and despite its simplicity it is quite powerful and allow performance of the additional checks via PAM mechanism that increases security. 

One important system group which is identified by its name and not by its GID is called wheel.  In RHEL it has GID 10.  It contains the list of system administrators for the server (users who have legitimate rights to become root) and is usually used (via sudo) to give this subset of users the ability to switch to root, independently whether they know root password or not.  This idea of wheel group like many other brilliant ideas came from BSD. Another group that often has extended privileges via sudo in the operator group, but its semantic is less well defined.

SUID vs SGID vs Sticky Bit

Every directory and file on the system has an owner, and also an associated group. It also has a as additional three permission flags which modify the meaning of specified res/write/execute permissions for the 'user' (SUID)  'group' (SGID), and 'other' (sticky bit). 

1. Owner  (The file's owner) You can specify read, write execute permission and one additional attribute for files:
   • SUID Attribute: (For Files) This describes set-user-id permissions on the file. When file is executed the run time UID is set of the owner of the file not the  user who is executing the file. The most important case is when file is owned by root. In this case when that file is executed the run time UID is set to root. That means that the program executes as if it is owned by the root, and is granted access to all system resources. There are several dozen of such files in Linux and they are the cause of many "buffer overflow" exploits.  Usually files that have this bit are subject to strict security audit, and assigning this bit to a "rogue" program means that the security of this server is completely compromised. 
2. Group (Users who are in the file's group) You can specify read, write execute permission and one additional attribute for directories:
   • SGID Attribute: (For directories) changes the rules of inheritance for new files in this directory: If you set the SGID bit on a directory (with chmod g+s directory), files created in that directory will have their group set to the directory's group.  Historically 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 user and/or the  group). Generally SGID attribute should not be used with world writable directories.  
3. Other  Everybody else on the system ( except the superuser, owner and members of the group assigned to the file ). 
   • Sticky bit prohibit deletion of files by anybody but the owner of the file, thus ignoring this part of directory permissions. Sticky attribute (sticky bit)  controls the ability to delete file that do not belong to an owner in writable directories. This is 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 Linux and other Unixes by default has a sticky bit set.

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

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.

NOTE: 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 relevant.

Inheritance of permissions, umask

In Unix umask controls how file permissions are set for newly created files. the structure of the mask is identical to structure of file permissions. This concept was introduced around 1978, between the sixth edition and the eighth edition of the operating system. Like regular file permissions umask can be represented in binary, octal or symbolic notation. And the umask command allows the mask to be set in all three notations.

It may be changed by invoking the umask command. The syntax of the command is:

umask [-S ] [maskExpression]

The items within the brackets are optional. The -S argument (i.e. umask -S) will force umask to display using symbolic notation

If the umask command is invoked without any arguments, it will display the current mask.

$ umask         # display current value (as octal)
0022
$ umask -S      # display current value symbolically
u=rwx,g=rx,o=rx

If the umask command is invoked with an argument, it set the bits of the mask to that argument. For example:

$ umask 007    # set the mask to 007
$ umask        # display the mask (in octal)
0007           #   0 - special permissions (setuid | setgid | sticky )
               #   0 - (u)ser/owner part of mask
               #   0 - (g)roup part of mask
               #   7 - (o)thers/not-in-group part of mask
$ umask -S     # display the mask symbolically
u=rwx,g=rwx,o=

If fewer than 4 digits are entered, leading zeros are assumed. An error will result if the argument is not a valid octal number or if it has more than 4 digits. If a fourth digit is present, the leftmost (high-order) digit defines three additional attributes, the setuid bit, the setgid bit and the sticky bit.

Prohibit write permission from being set for the user. The rest of the flags in the mask are unchanged.

Example of multiple changes:

umask u-w,g=r,o+r

This would set the mask so that it would:

1. prohibit the write permission from being set for the user, while leaving the rest of the flags unchanged;
2. allow the read permission to be enabled for the group, while prohibiting write and execute permission for the group;
3. allow the read permission to be enabled for others, while leaving the rest of the other flags unchanged.

Here are more examples of using the umask  command to change the mask.

Example showing effect of umask:

$ umask -S       # Show the (frequently initial) setting 
u=rwx,g=rx,o=rx
$ gcc hello.c      # compile and create executable file a.out
$ ls -l a.out 
-rwxr-xr-x  1 me  developer  6010 Jul 10 17:10 a.out 
$ # the umask prohibited Write permission for Group and Others
$ ls  > listOfMyFiles    # output file created by redirection does not attempt to set eXecute
$ ls -l listOfMyFiles
-rw-r--r--  1 me  developer  6010 Jul 10 17:14 listOfMyFiles 
$ # the umask prohibited Write permission for Group and Others
$ ############################################################
$ umask u-w  # remove user write permission from umask
$ umask -S
u=rx,g=rx,o=rx
$ ls > protectedListOfFiles
$ ls -l protectedListOfFiles
-r--r--r--  1 me  developer  6010 Jul 10 17:15 protectedListOfFiles 
$ rm listOfMyFiles
override r--r--r-- me/developer for protectedListOfFiles? 
$ # warning that protectedListOfFiles is not writable, answering Y will remove the file
$ #####################################################################################
$ umask g-r,o-r  # removed group read and other read from mask
$ umask -S
u=rx,g=x,o=x
$ ls > secretListOfFiles
$ ls -l secretListOfFiles
-r--------  1 me  developer  6010 Jul 10 17:16 secretListOfFiles

The mask is applied whenever a file is created. If the mask has a bit set to "1", that means the corresponding file permission will always be disabled when files are subsequently created. A bit set to "0" in the mask means that the corresponding permission will be determined by the requesting process and the OS when files are subsequently created. In other words, the mask acts as a last-stage filter that strips away permissions as a file is created; each bit that is set to a "1" strips away that corresponding permission for the file.

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). The primary group is defined in /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 and the sources of this inheritance. New files created by the users have to start out with some set of permissions.  There are two models of accomplishing this task -- BSD and SysV

• BSD:  New files are owned by the creator of the file
  • default group set to user primary group (from password file).
  • Actual values of the permissions are determined by the value of umask.
• SysV:  New files are owned by the creator of the file,
  • default group set either from a password file or from the group of the parent directory (if setgid bit set on parent directory).
  • Permissions are determined from the value of umask.

Those days there are no pure BSD/SysV systems left. Most systems are hybrid.

User private groups

This is quite recent attempt to extend the Classic Unix model busing a very simple idea: user primary group should be unique and contin only this particular user and no other users. This is  the concept behind so called User Private Groups (UPG) initially introduced in Red Hat, but abandoned in RHEL6.  This is an interesting idea --  a new convention for assigning primary groups to real (human) users: each of them gets unique primary group with the GID value equal to their UID. Whenever you create a new user, by default, he or she is assigned a unique group that has GID equal to UID. 

Assuming each user is the only member of its user private group, this scheme allows an umask of 002 to be used without allowing other users to write to newly created files in normal directories because such files are assigned to the creating user's private group. However, when sharing files is desirable, the administrator can create a group containing the desired users, create a group-writable directory assigned to the new group, and, most importantly, assign to the directory SETGID bit.

Such scheme makes removal of users much easier. It also makes home directories more secure, as by default they are assigned the value of user primary group. If this group contains other users (for example,  if this group is users),  they all acquire access to this particular user home directory, unless group permissions  are set to 0 or you have a very strict umask for the system. This is just a procedural enhancement, which does not add or change anything in the standard UNIX way of handling groups but like other useful procedural enhancement such as special role of wheel group or system groups, it increases the security and flexibility of Unix classic permission model.

Again, as groups assignment is essentially assignment of roles in large organizations is it might bogglingly complex. Often it is screwed up in major way -- for example group is assigned based on organizational unit in Active Directory.  Which for some users is too restrictive but  for other users way too permissive.  At the end of the day it leads to excessive  number of users who have access to root via sudo, as they can't accomplish their job within a straitjacket put by their group membership. 

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 created with a file permission of "rwxrwxrwx" (or mode 0777). These file permissions are ignored by the operating system.

Interpretation of ls -l listing

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:

-rw-------
drwxr-xr-x

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

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". S means that SUID or SGID bit is set. 't' means sticky bit is set.

For example, there are several files with SUID root in /usr/bin directory of RHEL7. They all have the third letter of owner permissions changed to 's':

bezroun@test01:/usr/bin # ll | grep rws
-rwsr-xr-x. 1 root root     52K Apr 11  2018 at*
-rwsr-xr-x. 1 root root     63K Nov  5  2016 chage*
-rws--x--x. 1 root root     24K Aug 16 18:47 chfn*
-rws--x--x. 1 root root     24K Aug 16 18:47 chsh*
-rwsr-xr-x. 1 root root     57K Apr 11  2018 crontab*
-rwsr-xr-x. 1 root root     77K Nov  5  2016 gpasswd*
-rwsr-xr-x. 1 root root     44K Aug 16 18:47 mount*
-rwsr-xr-x. 1 root root     41K Nov  5  2016 newgrp*
-rwsr-xr-x. 1 root root     28K Jun 10  2014 passwd*
-rwsr-xr-x. 1 root root     28K Apr 11  2018 pkexec*
-rwsr-xr-x. 1 root root     32K Aug 16 18:47 su*
-rwsr-xr-x. 1 root root     32K Aug 16 18:47 umount*

If ACL attributes are present there is an additional character "+" following the permission characters for "other" in ls -l listing:

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

In the example above 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.

The order of interpretation of permissions

Permission are interpreted in the order -- owner, group, other. If at some point you are allowed or denied the requested access based on you file ownership or membership, other permissions are not interpreted. In case you are denied access you are simply out of luck. For example, if the file has the owner permissions set to rw-, and you are the owner and try to execute it, you will be denied access even if you are member of the group specified for the file and that that group has requested access say read access to the file).  If you are denied access as the member of the group specified, it does not matter for you what "other permissions are set", you are still out of luck.  Of course, if you are the owner nothing prevents you from changing permissions for this file, so the first example with owner is kind of artificial. 

That means that permission 005 means: anybody but the owner and the members of the group can read and execute this file.

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

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

• You can set the permission of each file to 0600, so only you have read/write access.
• You can put the files in a directory and set the permission of that directory to 0700, which prevents other users from accessing the files in the directory (or in any of the directory's subdirectories) unless there is a hard link to each file from somewhere else.

Notes:

• You must have execute access for a directory to make it your current directory (via cd or chdir) or to change to any directory beneath (contained in) that directory.
• If you do not have execute access to a directory, you cannot access the files within that directory, even if you own them.
• If you have execute access to a directory but do not have read access, you cannot list the names of files in the directory (e.g., you cannot read the contents of the directory). However, if you have access to individual files, you can run programs in the directory or open files in it. Some sites use this technique to create secret files—files that users can access only if they know the files' full pathnames.
• To unlink a file from a directory, you need to have write and execute access to that directory, but not to the file itself.
• Remember that the directory itself contains only name and inode information. If you have read access to a directory but do not have execute access, you can display a short listing of the files in the directory (ls); however, you will not be able to find out anything about the files other than their names as all attributes are stored in the inode of the file. 

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.

How ACL permissions are bolted on classics Unix permission model

Posix ACL extend the concept of the group, adding into the mix Windows permission model

This is "bolt on" addition to classic Unix permission model, which never was formally ratified but still is present in Red Hat.  It is a "bot on" solution, badly engineered, very difficult to understand and contain numerous traps and pitfalls. That's probably why it was never ratified by Posix and exists only as draft.

Like VMS and Windows (which is derivative of VMS) this model is file centric:  you can assign the set of rights to individual file or a group of files. Moreover if they exist, those permissions have higher priority and overwrite classic Unix permissions.  One positive aspect is that it now allow to eliminate the limitation the in classic Unix permission model in which each group is atomic -- it can consists only of users, but not groups.  Now you can assign arbitrary permission for particular user on individual file basis. 

The main  drawback of this model is that it is almost impossible to understand and it is not well integrated with classic Unix permissions (ls does not display them, but just indicates their presence). It smells "beta".

ACLs behaves differently for files and directories:

• Directories permissions work as in classic Unix: they are owner definable and owner of a new directory is the user who created the directory.  Directtories are also assigned an additional set of ACLs called "default ACL" . Those default ACLs entries are used as default to set the ACL on every file created within the directory. In other words this is generalization of the concept of umask:  you can understand default ACLs as umask assigned on "per directory" basis. 

  When you create a directory, you can simultaneously set default ACL entries for the owner, owner's group, others, and the ACL mask for this directory.

  1. d[efault]:u[ser]::<perm> Sets the default permissions for the owner of the directory.
  2. d[efault]:g[roup]::<perm> Sets the default permissions for the owner's group.
  3. d[efault]:o[ther]::<perm> Sets the default permissions for users other than the owner or members of the owner's group.
  4. d[efault]:m[ask]::<perm> Sets the default ACL mask.
  5. d[efault]:u[ser]:<UID>:<perm> Sets the default permissions for a specific user.
  6. d[efault]:g[roup]:<GID>:<perm> Sets the default permissions for a specific group.
      
• File permissions work differently. If the directory in which file is created has default ACL set, then a new file inherits the default ACLs of their parent directory. ACL permissions are not static. Each time the file is accessed the effective permissions are calculated from combination of the Unix permissions, the ACL permissions and an  ACL mask. The latter can be viewed as an extension of the concept of Unix umask to regular file operations (umask works only during the creation of the file). It defines the maximum permissions allowed for owner and groups that were granted the access rights to the file via ACL mechanism and overwrites all other settings. 

  There are two cases here

  • File has no ACLs at all. In this case it is assumed that the file has so called "trivial ACL" that consists just of ACL mask. The latter always equals to rwx so its application does not change group permissions and does not affect access in any way.  In other words ACL does not  affect access to such a file.
  • If ACL for a file is set, then default ACL mask is set to be equal to group permissions. ACL mask does not influence regular (classic Unix) owner and world (others) permissions. If affects group permissions modifying and overwriting them for additional owners (ACL owners, which can be multiple) and additional groups ( which also can be multiple) narrowing or extending the set of users defined by classic Unix group.   Again ACL overwrite group permissions only.
    • To get effective permission the initial (static) permission are ANDed with the complement of ACL mask (exactly like default file permission with umask; to calculate actual permissions granted, the complement of the umask value (the bits that are not set in the umask ) is combined with the default permissions using bitwise AND. ). In other words ACL mask is an extension of the idea of umask to operations outside creation of the file (classic Unix umask is limited to creation of the file).

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 troup. 

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:

• u = user (owner)
• g = group
• o = others
• a = all, or ugo

and operator can be:

• + add this permission
• - take away this permission
• = make this permission equal to

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

• News
• Recommended Links
• What is SGID and how to set SGID in Linux - The Linux Juggernaut

Etc

Society

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

Quotes

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

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

History:

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 DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting 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-Month :  How 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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

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 Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. 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.

Last modified: March 12, 2019