Something that you don’t know about Chmod under Linux

If you are working on Linux environment and working on some programs/scripts then you might have used chmod often for sure. Many of us think that what’s there in chmod to remember. Why people write so many articles on one of the simplest command in Linux which even a newbie use it like anything.
Then my question to all Linux users is that “how many octets a full permissions set have?”. I know, many Linux users would say three within three seconds but it’s four literally. Stumped right?

Usually we write
[vim]
chmod 777 file
[/vim]
But what we are actually saying:
[vim]
chmod 0777 file
[/vim]

The first octet works the same way as the other three works, as it has the same 3 possible values that adds to make the octet :
4 – setuid (letter used for it: s)
2 – setgid (letter used for it: s)
1 – sticky bit (letter used for it: t)

Note: your first octet will always be reset to 0 when using chown or chgrp on files. We need not to worry when using chown and chgrp. It’s effective only on chmod then: D

Let’s see what those 3 values mean for the first octet.
Setuid (4 or s)
Using digit 4 or s for any file means you are setting a userid to that files i.e. setuid. If you do setuid on binary files, you’re telling the operating system that you want this binary file to be executed as the owner of the binary file always.

So, let’s say the permissions on a binary are set like this:
[vim]
# chmod 4750 some_binary
# ls -al some_binary
-rwsr-x— 1 root coders 0 Feb 13 21:43 some_binary
[/vim]

You’ll notice the small ‘s’ in the user permissions blocks instead of x  – this means that if a user on the system executes this binary, it will run as root with full root permissions. Anyone in the coders group can run this binary too! Because the execute bit is set for the group also. So, when the binary will get executed, it will run with root permissions. Isn’t it fascinating (Kind of masquerading without credentials 😛 )

Be cautious with setuid! Anything higher than 4750 can be proved dangerous else it would allow everyone to run the binary as the root user. Also, if you allow full access plus setuid, you will be opening yourself up for the real mess:

[vim]
# chmod 4777 some_binary
# ls -al some_binary
-rwsrwxrwx 1 root coders 0 Feb 13 21:43 some_binary
[/vim]

Not only can every user on the system execute this binary, but they can edit it before it runs at root! It goes without saying, but this could be used to beat up your system pretty badly. If you don’t allow enough user permissions for execution to anyone, Linux will throw the mysterious error as uppercase ‘S’ into your terminal:
[vim]
# chmod 4400 some_binary
# ls -al some_binary
-r-S—— 1 root coders 0 Feb 13 21:43 some_binary
[/vim]

Since no one can execute this script anyways (except root), you get the capital ‘S’ in output.

Setgid (2 or s -> little confusion right?)
Setgid is almost same as setuid, but the binary runs with the privileges of the owner group rather than the user’s privileges. This isn’t quite so useful in I guess, but in case you need to know what’s this so I wrote minimal amount of it :D, here’s how the permissions come out:
[vim]
# chmod 2750 some_binary
# ls -al some_binary
-rwxr-s— 1 root coders 0 Feb 13 21:43 some_binary
[/vim]

And if you again neglect the execution permission to everyone you get ‘S’ but this time group’s execution place:
[vim]
# chmod 2400 some_binary
# ls -al some_binary
-r—-S— 1 root coders 0 Feb 13 21:43 some_binary
[/vim]

Sticky Bit (1 or t)
This one is the trickiest term for a Linux file permission, and very important too. Its best example is your world writable /tmp directory (or any other world writable location like /var/log/ etc). Since world writable locations allow users to do anything with creating, editing, appending, and deleting files, which can be a total haphazard if certain users share a common directory and users like me played a prank by deleting it: P.

Let’s say users work in an organization and they work on a file in a world writeable directory. One user gets mad upon the false praise of other coders from his manager. So, he deleted all of the files that belong to that poor user L . Obviously, this could lead to a much more vulnerable situation. If you apply the sticky bit on the directory, the users can do anything they want to that files  but they can’t write to or delete files which they didn’t create (They can create new file though). Awesome feature, right? Now, how you can set the sticky bit:
[vim]
#chmod 1777 /tmp
# ls -ld /tmp
drwxrwxrwt 3 root root 4096 Feb 13 21:57 /tmp
[/vim]

If you want to see T instead of t in your output, please do the same mistake that I pointed in above two points i.e. don’t give execute permission to anyone. 😛
[vim]
#chmod 1744 /tmp
# ls -ld /tmp
drw-r–r-T 3 root root 4096 Feb 13 21:57 /tmp
[/vim]

How this setuid and setgid works on directory?
Setting the setgid bit on a directory means whatever files you have created in that directory will be owned by the group who owns the directory. No matter what your primary group is, any files you make will be owned by the group who owns the directory.

setuid is meant to implement on files especially binary files. So, setting the setuid bit on a directory has no effect in almost all Linux Distros. I didn’t test much on this to various *nix variants.

For your knowledge: The setuid bit was invented by Dennis Ritchie. His employer, AT&T, applied for a patent in 1972; the patent was granted in 1979 as patent number US 4135240 “Protection of data file contents”. The patent was later placed in the public domain.

So, if you are interested, please do some homework and let us know also what special stuffs you found there 😀