The read, write and execute permissions apply slightly differently to directories than they do to files. The read permission on a directory controls the ability to list the contents of that directory. In this example we’ll create a directory and place a blank file in it. We’ll then modify the permissions on the directory so the owner cannot see the contents.$ mkdir secret_dir
$ touch secret_dir/my_secret.txt
$ ls secret_dir/
my_secret.txt
$ chmod u-r secret_dir/
$ ls secret_dir/
ls: secret_dir/: Permission denied
$ cd secret_dir/
$ ls
ls: .: Permission denied
$ cd ../

We see that we get a Permission denied error when trying to view the contents of the directory when the read permission has been revoked. Despite not being able to see what is in the directory we can still change our working directory to that directory.

The write permission on a directory behaves somewhat as expected. If a user has write on a directory they can create or remove files from that directory even if they are not the owner of the files. This is important to note as giving a user, group or other users write on a directory with other user’s files in it will allow them to delete other users files.

Now we’ll give read permissions back to the owner and revoke the execute permission:

$ chmod u+r secret_dir/
$ chmod u-x secret_dir/
$ ls secret_dir/
my_secret.txt
$ cd secret_dir/
-bash: cd: secret_dir/: Permission denied

We can now view the contents of the directory again but look at what happened when we tried to cd into it! Not having the execute permission on a directory will prevent you from changing into that directory even though you can view the contents. It is understandable how this can cause some confusion.
 

Chmod and sticky bits

There are a few special permission mode settings that are worthy of noting. Note that the Set UID and Set GID permissions are disabled in some operating systems for security reasons.
 

Mode	Description
Sticky bit	Used for shared directories to prevent users from renaming or deleting each others’ files. The only users who can rename or delete files in directories with the sticky bit set are the file owner, the directory owner, or the super-user (root). The sticky bit is represented by the letter t in the last position of the other permissions display.
SUID	Set user ID, used on executable files to allow the executable to be run as the file owner of the executable rather than as the user logged into the system. SUID can also be used on a directory to change the ownership of files created in or moved to that directory to be owned by the directory owner rather than the user who created it.
SGID	Set group ID, used on executable files to allow the file to be run as if logged into the group (like SUID but uses file group permissions). SGID can also be used on a directory so that every file created in that directory will have the directory group owner rather than the group owner of the user creating the file.

The following example displays the SUID permission mode that is set on the passwd command, indicated by the letter s in the last position of the user permission display. Users would like to be able to change their own passwords instead of having to ask the System Administrator to do it for them. Since changing a password involves updating the /etc/passwd file which is owned by root and protected from modification by any other user, the passwd command must be executed as the root user.

The which command will be used to find the full path name for the passwd command, then the attributes of the passwd command will be listed, showing the SUID permission(s).

$ which passwd
/usr/bin/passwd
$ ls -l /usr/bin/passwd
-r-s–x–x 1 root root 17700 Jun 25 2004 /usr/bin/passwd

Here we see not only that the SUID permissions are set up on the passwd command but also that the command is owned by the root user. These two factors tell us that the passwd command will run with the permissions of root regardless of who executes it.

These special modes can be very helpful on multi-user systems. To set or unset the sticky bit use the the t option with the chmod command. When setting the sticky bit we do not have to specify if it is for user, group or other. In the following example we will make a directory called public which anyone can write to but we’ll use the sticky bit to make sure only the file owners can remove their own files.

$ mkdir public
$ chmod 777 public
$ chmod +t public
$ ls -l
total 4
drwxrwxrwt 2 tclark authors 4096 Sep 14 10:45 public

We see that the last character of the permissions string has a t indicating the sticky bit has been set. We could also prefix the number 1 to the chmod command using the number to achieve the same results. The following chmod command will accomplish the same thing as the two chmod commands in the last example:

$ chmod 1777 public
$ ls -l
total 4
drwxrwxrwt 2 tclark authors 4096 Sep 14 10:45 public

Now let’s say we instead want to make a directory which other users can copy files but which we want the files to instantly become owned by our username and group. This is where the SUID and SGID options come in.

$ mkdir drop_box
$ chmod 777 drop_box
$ chmod u+s,g+s drop_box
$ ls -l
total 4
drwsrwsrwx 2 tclark authors 4096 Sep 14 10:55 drop_box

Now anyone can move files to this directory but upon creation in drop_box they will become owned by tclark and the group authors. This example also illustrates how you can change multiple levels of permissions with a single command by separating them with a comma. Just like with the other permissions this could have been simplified into one command using the SUID and SGID numeric values (4 and 2 respectively.) Since we are changing both in this case we use 6 as the first value for the chmod command.

$ chmod 6777 drop_box/
$ ls -l
total 4
drwsrwsrwx 2 oracle users 4096 Sep 14 10:55 drop_box