What are files?
As we’ve discussed before, files are globs of data, in either text or binary form.
File names can be up to 256 characters long with “-“, “_”, and “.” characters along with letters and numbers.
When you do a long file listing, you see 10 characters on the left that indicate file type and permissions:
What are permissions?
File and directory permissions define your access to those files or directories.
There are actually three sets of permissions:
And there are three distinct permissions for each user or group:
which determine what level of access they have.
Every user’s profile defines what permissions will be given to files and folders created by that user.
When the user is created, a home directory for that user is created at /home/username, and the initial contents are copied from /etc/skel. (You can change these content files to change new user defaults.)
Triple Triplets: User, Group, Others
When you run an ls command, user permissions for directories look like:
User permissions for files look like:
The first character in the field indicates a file type of one of the following:
d = directory
l = symbolic link
s = socket (a connection to send data from a process on one computer to a process on another)
p = named pipe (a connection to send data from one command or process to another; represented as a file)
– = regular file
c= character (unbuffered) device file
b=block (buffered) device file
Types of permissions
There are 5 possible characters in the permission fields. They are:
r = read – This is only found in the read field.
w = write – This is only found in the write field.
x = execute – This is only found in the execute field.
s = setgid/setuid – This is only found in the user or group execute field
t = set text attribute, which shows up in the others execute field
If there is a “-” in a particular location, there is no permission given. This may be found in any field whether read, write, or execute field.
The first rwx refers to the owner’s permissions.
By default, the owner gets full permissions: read, write and execute:
The second triplet describes the permissions set for the default group of the owner, for instance:
which allows group members to read and execute the file, but not write to it.
(Generally a new group is created for every new user, but you can override this behavior and place your new user in another group.)
The last triplet describes the permissions granted to any other user. You might, for instance, only allow them to read your files, but deny them write or execute access:
Permissions are additive
If a user is both a member of the Group-permission group, and is (always, of course) a member of Others, the permissions that user will have are additive, which is to say they add together, rather than subtracting from each other.
Note the permissions of this file:
-rwxr–r-x root wheel … myfile.txt
Root owns the file; the wheel group has read permissions; Others have execute permissions. A member of the wheel group will get both the read permission from the Group triplet, and the execute permission from the Others triplet.
The shell command chmod changes file and directory permissions.
Generally you’ll use numeric permissions, though you can use alphabetic mode to modify permissions also (see man chmod.)
chmod 755 ~/myfile.sh
Numeric permissions are calculated by adding individual permissions.
4 means “read”
2 means “write”
1 means “execute” or “browse” (depending on whether you’re changing a file or a directory).
It all adds up
Add 1, 2 and 4 to describe a permission set.
1+4 = 5 (read and execute/browse)
1+2 = 3 (read and write)
1+2+4 = 7 (read, write, execute/browse)
Three triplets, three numbers
Remember, you can set groups for the owner, their group, and other users. This means you’ll use three numbers to describe a full set of permissions:
chmod 755 ~/myfile.txt
sets permissions to:
Careful with that directory!
The “x” permission has special consequences for directories. You might think you should eliminate “execute” permissions for directories that don’t contain executables.
That would be wrong. If you deny “x” permissions on a directory, users will not be able to browse to that directory.
Directory permissions don’t work the same way file permissions do. In particular, the execute permission is very different.
Meaning for files
Meaning for directories
User can open and read a file
User can list contents of a directory – only if user also has execute permission!
User can open, read and edit file
User can add files to or remove files from the directory
User can execute the file (if it’s executable)
User can enter directory and work with its contents. This is sometimes called the search permission.
Important Note: A user’s permissions on a directory do not transfer to the contents of the directory! Individual file permissions still prevail.
Some common permissions
chmod 777 ~/myfile.txt (= rwxrwxrwx)
chmod 755 ~/myfile.txt (= rwxr-xr-x)
chmod 644 ~/myfile.txt (= rw-r–r–)
chmod 000 ~/myfile.txt (= ———)
When should you allow execute permissions?
There are two times you’ll want to give users an “x” permission:
When you want to let them enter and browse directories.
When a file is a shared executable, for instance a Perl file used in a web site.
So far, we’ve described permissions using numbers, which works in most cases.
Be aware that you can modify permissions by “adding” or “subtracting” individual permissions.
For instance, if you wanted to remove execute permissions (for yourself) from a file named myfile, you could issue the command:
chmod u–x myfile
Effectively, you just “subtracted” execute permission.
Notice that in that last command,
chmod u–x myfile
we didn’t specify a user name. That’s because we just modified the owner’s permissions.
If we want to modify the group’s permissions, the command becomes:
chmod g-x myfile
Even more, if a category of user is not specified, ALL users are assumed:
chmod -x myfile
removes everyone’s execute permission.
Why the heck do we want to do this?
You can use this feature for quick modifications of permissions, but its real use is in setting the
User Identification Attribute
(Let that one sink in.)
Let’s get abstract. Under Unix, every file (which means everything) is owned by someone.
Further, every process that’s executed is also owned by someone.
The trick question is, who “are” you as you run an executable file that belongs to someone else?
The answer is, it depends.
Under most circumstances, you execute executables as yourself, with all the permissions (and restrictions) you have.
However, there are some programs that have to be run as someone else. Consider services, for instance.
What is a service? A service is a utilitarian program that is run by a daemon, which is the process that actually sits and waits for a signal. The daemon provides the service.
So what? Here’s what: daemons run even when no one is logged in. They’re running in kernel mode as opposed to user mode.
And what does “daemon” mean? Disk Access and Execution MONitor
Set the User ID Attribute
Recall that the file permissions bits include an execute permission bit for file owner, group and other.
When the execute bit for the owner is set to “s” the set-user-ID bit is set. This causes any persons or processes that run the file to have access to system resources as though they are the owner of the file. When the execute bit for the group is set to “s”, the set-group-ID bit is set and the user running the program is given access based on access permission for the group the file belongs to. The following command:
chmod u+s myfile
sets the user ID bit on the file “myfile.”
The ping command is an example of a command with SUID. ping can be called by anyone, but it runs as root – it has to, for some of its functionality.
NOTE: You can only SUID compiled binary programs on some platforms. Test this on yours.
Set the Group ID Attribute
chmod g+s /somedir
sets the group ID bit on the directory “/somedir”.
These two items have the group or user ID bit set:
-rws–x–x 1 root root 14024 Sep 9 1999 chfn
-rwxr-sr-x 1 root mail 12072 Aug 16 1999 /locks
Set UID/GID Examples
-rws–x–x 1 root fred 14024 Sep 9 1999 chfn
-rwxr-sr-x 1 root mail 12072 Aug 16 1999 /locks
The “s” takes the place of the normal location of the execute bit in the file listings above.
This special permission mode has no meaning unless the file has execute permission set for either the group or other as well. This means that in the case of the lockfile, if the other users (world execute) bit is not set with permission to execute, then the user ID bit set would be meaningless since only that same group could run the program anyhow.
In both files, everyone can execute the binary. The first program, when run is executed as though the program is the root user. The second program is run as though the group “mail” is the user’s group.
So Please Note: SUID/SGID will only work if execute permissions on lower triplets are set as well.
Careful with that axe
For system security reasons it is not a good idea to set many program’s set user or group ID bits any more than necessary, since this can allow an unauthorized user privileges in sensitive system areas. If the program has a flaw that allows the user to break out of the intended use of the program, then the system can be compromised.
Special Directory Permissions
There are two special bits in the permissions field of directories. They are:
s – Set group or user ID (SGID/SUID)
t – Save text attribute – The user may delete or modify only those files in the directory that they own or for which they have write permission.
Directory Set Group ID
If the setgid bit on a directory entry is set, files in that directory will have the group ownership of the directory, instead of the group of the user who created the file.
Special Directory Permissions
This attribute is priceless when people are working on projects.
If users work in a directory with the setgid attribute set, any files created in the directory by any of the users will have the permission of the directory group, rather than the user’s default (primary) group.
For example, the administrator creates a group called project and adds the users Kathy and Mark to the group project. The directory projectdir is created with the set GID bit set. Kathy and Mark, although in different primary groups, can work in the directory and have full access to all files in that directory – but still not be able to access files in each other’s primary group.
Setting the GID bit
Issue this command to set the GID bit on a directory:
chmod g+s /projectdir
Resulting in this directory listing of the directory projectdir:
drwxrwsr-x 2 kathy project 1674 Sep 17 1999 projectdir
The “s” in place of the execute bit in the group permissions causes all files written to the directory projectdir to belong to the group “project.”
Save text attribute (the “sticky bit”)
The /tmp directory is typically world-writable and looks like this in a listing:
drwxrwxrwt 13 kathy project 4096 Apr 15 08:05 tmp
Everyone can read, write, and access the directory. The “t” indicates that only the user who created a file in this directory can delete or modify that file. Root always can overrule this, of course.
Setting a sticky bit
To set the sticky bit in a directory, issue the following command:
chmod +t directory_name
So why would you do this?
This setup is one step “tighter” than the set GID setup.
If you didn’t create the file, you can’t change or delete the file. But otherwise you can work freely in the directory.
If you set the GID bit instead, anyone with access to the directory can modify anyone else’s files. However, in many programming situations, this is a good thing.
Using numerical values for special permissions
You can use the numerical values of chmod to set special permissions:
4 = SUID
2 = SGID
1 = Sticky Bit
So, for example, you could set the sticky bit using:
simply by placing an additional number to the left of the permission set.
Examples of making changes to permissions
chmod u+x myfile
Gives the user (owner) execute permission on myfile.
chmod ugo+x myfile
Gives everyone execute permission on myfile.
chmod 400 myfile
Gives the user read permission, and removes all other permission.
chmod 764 myfile
Gives user full access, group read and write access, and other read access.
chmod 751 myfile
Gives user full access, group read and execute permission, and other, execute permission.
chmod u+s myfile
Set the setuid bit.
chmod go-rx myfile
Remove read and execute permissions for the group and other.
Quick: when you create a file, who owns the file?
What group “owns” the file?
What are its default permissions?
We’re into the realm of a concept called the umask: the “user mask.”
The umask is a numerical value that describes the default permissions any file you create will have.
You can see your own current umask with the command:
The numbers look similar to file permission numbers, like 421. However, they function differently.
About masks in general
A user mask is just one kind of mask you’ll find in the world of Unix.
Another common one is the subnet mask, a number like:
Here’s the thing to know:
Masks are subtractive, not additive.
The subnet mask 255.255.255.0 actually means (in the case of an IP address), “subtract this value from the maximum possible values.”
In this case it means, “mask the first three octets (triplets) of local IP addresses.” In other words, if my IP is 192.168.0.5, and I’m trying to reach 192.168.0.7, the address I’ll really look for is simply 0.0.0.7.
If you’re not familiar with this concept in IP addressing, don’t worry about it.
Instead, consider the highest possible level of permissions a file can have, expressed as numbers:
777 for executable files
666 for text files
Note that contemporary Linux distros won’t even allow you to create a file as executable by default. This is a good idea.
Better than 666
777, as a file permissions descriptor, means the user, group and others all have read, write and execure permissions.
I don’t want everyone to have full permissions to my files. I want them to have less. In fact, for most cases, I want them to have:
However, this may be too draconian, so I’ll settle for:
755 (for executables)
644 (for text files)
umask: the numerical value
So, if I want to “lower” the default permissions that a file I create will have, I have to subtract from 777 (for executables) or 666 (for text files.)
If I’m keeping full permissions for myself, the first number of my umask will be 0.
If I’m restricting my group members to reading and executing, but not writing to my files, the second number of my umask will be 2 (thus subtracting 2, or the “write” value) for any file I create.
And if I’m willing to give the same read/execute permissions to others, the third number of my umask will also be 2 (thus subtracting write permissions).
Setting my umask
You can set the value of your shell’s umask from any shell prompt.
umask is a built-in bash shell command. The preferred way to set it is to add a umask command to the .profile or .bashrc file in your home directory.
To change it system wide there is a file in the /etc directory hierarchy where the default values for user shells are set.
System default umask
The system default umask is set in the file /etc/bashrc, which is generally modifiable only by system admins.
Its current default value is probably the best one for system wide use. For specific groups of users you may want a slightly more open value, but it shouldn’t be needed most of the time.
Your own umask
You can override the system default umask by setting your own in your home directory.
Modify either ~/.bashrc or ~/.bash_profile (preferably the second) to change your own umask permanently.
Use the umask command to change it only for the current session:
Think like chmod
The three digits of a umask are written in the same order as you’d specify with chmod: first, the user mask; then, the group; finally, all others.
So, a umask of 002 denies no (0) permission for the user owner and group owner, and denies write (2) permission for others. A umask of 027 would deny no (0) permission for user, write (2) permission for group, and all (7, or 4+2+1) permissions for other users.
umask by example
An easy way to see what a umask does is to set it, create an empty file and directory (with touch and mkdir), and then use ls -l to see the permissions (here we’re using the shell’s semicolon (;) operator to run two commands from a single prompt):
touch myfile; mkdir ymdir
ls -l myfile; ls -ld mydir
-rw-r—– glenn glenn … myfile
drwxr-x— glenn glenn … mydir
rm myfile; rmdir mydir