Linux Modes and Permissions - Sticky Bit

A new problem

Now if I create another file in share that also needs to be shared. I need to change the group of very file I plans to share and sometimes the permissions also. This is not workable. I create 2 files – efile and list.sh. (list.sh is ug+x)

eipe@eipe-system:~/share$ ls -l total 12 -rw-r–r– 1 eipe egroup 15 2010-12-12 18:29 efile -rwxr-xr– 1 eipe dev 7 2010-12-12 16:39 lister.sh -rwxr-xr– 1 eipe egroup 3 2010-12-12 18:35 list.sh

we see that the new files created has the creator’s group!!!

Does changing the group of the parent directory help? Let’s try.

eipe@eipe-system:~$ chgrp dev share

tom log’s in.

tom@eipe-system:/home/eipe/share$ ./list.sh bash: ./list.sh: Permission denied tom@eipe-system:/home/eipe/share$ cat>tfile bash: tfile: Permission denied tom@eipe-system:/home/eipe/share$ rm efile rm: remove write-protected regular file efile'? y rm: cannot remove efile’: Permission denied

Tom cannot run/create/remove files within the group shared folder!!! (Note: folder is read-execute)

Solution:

Let’s make the directory writable.

eipe@eipe-system:~$ ls -l | grep share drwxr-xr-x 2 eipe dev 4096 2010-12-12 18:17 share eipe@eipe-system:~$ chmod g+w share eipe@eipe-system:~$ ls -l | grep share drwxrwxr-x 2 eipe dev 4096 2010-12-12 18:17 share

Now tom logs in.

tom@eipe-system:/home/eipe/share$ ./list.sh bash: ./list.sh: Permission denied tom@eipe-system:/home/eipe/share$ cat>tfile tom able to create file in this dir tom@eipe-system:/home/eipe/share$ rm efile rm: remove write-protected regular file `efile’? y

tom@eipe-system:/home/eipe/share$ ls -l total 12 -rwxr-xr– 1 eipe dev 7 2010-12-12 16:39 lister.sh -rw-r–r– 1 eipe egroup 3 2010-12-12 18:35 list.sh -rw-r–r– 1 tom tgroup 36 2010-12-13 18:44 tfile

Tom is able to create and delete file’s in the directory. But he won’t be able to execute or modify the files unless he modifies the individual file permissions and change group ownership to dev. (Note: Easy solution is to make it others-executable).

Default Permission Settings

Now you must have noticed the default behavior of unix. (provided default umask, 0022 in most systems, is not changed) Standard permission for file is 666 and for folder is 777. So folders and files get the permissions set as 777 - 022 = 755 666 - 022 = 644 (- denotes bitwise AND) Reason why files are not given executable permissions is security. Only the creator is allowed to make a file executable. Note: It allows users within the same group to

  1. create files in the shared folder
  2. delete files in the shared folder

It doesn’t allows users within the group to

  1. modify files in the shared folder Solution: make individual files g+w and group changed to dev.
  2. execute files in the shared folder Solution: make individual files g+x and group changed to dev.

We will see later that there is a short cut to make all files created in a folder to have the group ID of it’s parent folder. (setGID bit). But there is no shortcut to modifying permissions. You cannot set a umask on a folder but we could set a specific umask for a user by modifying the .bashrc file in a users home folder.

GROUP=grep $LOGNAME /etc/passwd | cut -f4 -d: if [ “$GROUP” == “YOURGROUP” ] then umask 007 fi

Thus our solution for the first problem is

  1. To change groupID of new files created in a folder to the folder’s groupID we manipulate setGID bit.
  2. To make the permissions same for all files created under the folder – is not possible. But we could limit the permissions of each user.

You might be wondering why the files are delete-able and not modifiable. The explanation lies in understanding the meaning of permissions on a directory and a file. Write on a file means the ability to edit the file. Write on a directory means the ability to create and delete files under it.

Now consider a situation when the group wants all it’s users to have only create and not delete permissions on a directory.

Solution: Sticky Bit

Sticky Bit

In olden times, the sticky bit was used to write a file (program) to memory so it would load more quickly when invoked. On Linux, however, it serves a different function. When you set the sticky bit on a directory, it limits people’s ability to delete things in that directory. That is, to delete a given file in the directory you either must own that file or own the directory.

To set the sticky bit, issue the command:

chmod +t directory_name

eipe@eipe-system:~$ chmod +t share eipe@eipe-system:~$ ls -l | grep share drwxrwxr-t 2 eipe dev 4096 2010-12-13 19:08 share

A uppercase T denotes that the directory is not other-executable and has the sticky bit set. A lowercase t denotes that the directory is other-executable and has the sticky bit set. Now tom log’s in.

tom@eipe-system:/home/eipe/share$ ls -l total 16 -rw-r–r– 1 eipe egroup 20 2010-12-13 21:07 efile -rwxr-xr– 1 eipe dev 7 2010-12-12 16:39 lister.sh -rw-r–r– 1 eipe egroup 3 2010-12-12 18:35 list.sh -rw-r–r– 1 tom tgroup 36 2010-12-13 18:44 tfile tom@eipe-system:/home/eipe/share$ rm efile rm: remove write-protected regular file efile'? y rm: cannot remove efile’: Operation not permitted .

Note: Sticky bit applies to directory one-level down. If there are directories inside, that also needs to be shared, then they also need to be manually applied sticky bit.

Continue reading here