What is Sticky bit?

Sticky bit is used for advance level file permission in Unix. It is one of the twelve bits used in File security.  Generally, users know only about nine bits which are used in File permissions, i.e. 3 for user/owner, 3 for Group to which the file owner belongs and 3 for others. There are 3 other bits also used for advance level file permissions

i) SUID bit

ii) SGID bit

iii) Sticky bit

I already explained the use of SUID bit in this post.

Sticky bit can be used with files, as well as directories. Sticky bit is rarely used with files these days. The main use of Sticky bit comes when it is used with directories.

Sticky bit with files

Sticky bit is used with files in order to make it persist in the swap area or memory. In earlier days when RAM was limited in size, the scheduler used to swap programs very swiftly from RAM to Hard drive. This would cause problems when the part of the program was used very frequently in some process. So, what the programmer would do. He used to set sticky bit on files which were used very frequently, in order to retain them in the memory.

Now a days we have RAM of very high capacities, so Sticky bit is rarely used on files.

Sticky bit with directories

The main use of sticky bit is with directories. For understanding this, we will have to understand  file permissions on directories.

Suppose there is a public directory,  "pubdir" , which has permissions like following

rwxrwxrwx

Since it is  a public directory, it has executable and write permissions for everyone. Now suppose, I have a file "myfile" which is in this public directory , and I have given it permission like following

rwxr- -r- -

I have not given write or execute permission to others. This means that any other user will not be able to edit or execute my file. But will heshe able to delete my file? Well that depends on the directory permissions in which my file is residing.

Now, let's understand "pubdir" directory permissions.

i) Everyone has read permission: Everyone will be able to see the contents of this directory using   ls -l.

ii) Everyone has execute permission: Everyone will be able to access the directory, access on a directory means, anyone can go inside directory using cd command.

iii) Everyone has write permission: Anyone will be able to edit/delete any of the contents of directory.

Now, what are the contents of a directory?...........wwwoooooo  FFFFFFFFiiiiiiiilllllllllleeeeeeeeeeessssssssss.

Damn it. All the files, owned by any user, are vulnerable to a lot of threats.

Now you understood the problem.

Don't worry, we have a solution in the form of Sticky bit. When we set sticky bit for a directory then it puts a restriction on the directory that only the file owner of the file, which is inside the directory, will be able to delete it, and not anyone else.

Sticky bit can be set in the following way.

chmod +t filename

After setting the sticky bit, the directory permission would look like

rwxrwxrwt

The most practical use of sticky bit is in /var/temp. temp directory is public and common to every user.

For more information visit

Why is SUID bit used?

Whenever a file, in which SUID bit is set by owner, is run by some user, the process runs with the identity and permission of owner and not of the user running the file.

Suppose we have a file "file1" whose permissions are shown as below.

-rwxr-xr-x

Let this file be owned by John. Now let there be another file "file2", owned by John, which has permissions as follows.

-rwxr- -r- -

 "file2" can only be modified by John, who is the owner of the file. Suppose, this file stores the information about the employees working under John. Lee is one of the employee working under John, i.e. Lee's data is also stored in "file2". Now if John had given write permission to others and groups, then anyone would have been able to change anyone's data using vi editor.

John didn't want that, but also he wanted to make things simpler. So, what he did? He didn't give write permission to any of the employees for "file2", instead, he made another file "file1" on which he gave execute permission to everyone. He also set the SUID bit for "file1" because of which,when some user tries to execute "file1", the process will be executed with John's identity and permission.

Now when the process is executing with John's identity, it can very well change the contents in "file2", since John has write permission on "file2". In other words, John has cutomized the changes which an employee can make to "file2".  Now a user cannot just open a file in vi editor and make any changes he/she wants. Instead, he will only be allowed to make changes in "file2" as determined by the program written in "file1".

So, that is the advantage of using SUID bit.

We set the SUID  bit for "file1" as

chmod +s file1

After the SUID bit is set, the file permissions for "file2" will be as follows

-rwsr-xr-x

Did you notice the 'x' bit in user set changed to 's' ?. This confirms that SUID bit has been set for "file1".

In this way "file2" could not be modified by any employee using vi editor but can be modified by script/program in "file1" using owner's permission. Wasn't that amazing?

 


For more information visit

How to take screenshot of the iPhone screen programmatically?

This post deals with taking screenshot of the iPhone screen with the help of coding.

Remember, when we say screen shot of the iPhone screen, we mean screenshot of any view which is visible on the iPhone screen. Also, a view is captured with all its subviews that are visible on screen at the time of capturing.

Add the following code at the place where you want to take screenshot of the view.

UIGraphicsBeginImageContext(view.frame.size);
CGContextRef context = UIGraphicsGetCurrentContext();
[view.layer renderInContext:context];
UIImage *theImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

A Context, more accurately known as Graphics Context, is the drawing destination for your objects. A context can be a Bitmap image, a UIView layer, a PDF file or a Printer.

In the above code, view is the UIView object which has to be captured.

UIGraphicsBeginImageContext(view.frame.size) creates a bitmap image context and set it as the current context. It takes size as parameter. The image context made is of the same size as the size passed in as parameter to this function. Since, here we want the image context to be of same size as of view to be captured so we pass the size of view as parameter.

UIGraphicsGetCurrentContext() returns the current context for drawing. Since we already set the bitmap context as the current context so it will return the same bitmap context created above. Had the bitmap context not been set , all the drawings would have taken place on UIView layer context(which is the default current context).

[view.layer renderInContext:context] draws all the objects, on or above the view’s layer, to the context passed in as parameter.

UIGraphicsGetImageFromCurrentImageContext() returns an image based on the contents of the current bitmap-based graphics context.