Linux
has some special attributes associated with all files. Often
in X Windows when you check the properties of any file (by right
clicking on it and viewing its properties) you would get to
see 3 special attributes besides the common read/write/execute
rights for the owner/group/others . The 3 extra attributes are
known as SUID, SGID and Sticky Bits
Sticky
Bit
Lets start with Sticky bit first. Since this is the most simplest
to explain. Setting the sticky bit tells Unix that once the
concerned application is executed, it should remain in memory.
Remember that Unix is a multi-user OS and was mainly designed
so that multiple users can work simultaneously. Thus the logic
used is that a program that exists in memory requires lesser
time to start when a new user requests for the same program.
Thus when one user has just used a program and then a new user
wants to use the same program, the second user doesn't have
to face a time delay for the program to initialize itself. It
would be readily available to him. The concept of the sticky
bit was a very useful one, long back when fast disk access and
other memory access technologies weren't around. But in today's
age the concept of sticky bit is obsolete, since modern day
technology is advanced enough to reduce the time delay while
loading applications into the memory. Thus currently the sticky
bit is of very little significance. Sticky bit is only associated
with executables.
SUID (Set User ID) Bit
Sometime you may faced an error while trying to run any application
stating that the application must be 'SUID root' . You might
have been confused that time, but now once you read this article
you would no longer find it confusing.
SUID stands for Set User ID. This means that if the SUID
bit is set for any application then your user ID would be set
as that of the owner of application/file rather than the current
user, while running that application. That means in case
I have an application whose owner is ' root ' and it has its
SUID bit set, then when I run this application as a normal user,
that application would still run as root. Since the SUID
bit tells Linux that the the User ID root is set for this application
and whenever this application executes it must execute as if
root was executing it (since root owns this file).
In case you have really understood the above you may be wondering
- isnt this a major security risk? If users are able to run
applications as root, then it must be definitely posing as a
threat to the security of the system. Actually the SUID is used
to increase the security in a way. Let me explain this with
my own example I use on my machine.
One way I use SUID on my machine
I have a few files that I modify through Linux and then before
I shutdown Linux I have to transfer them to my Windows partition
for further use there. As a normal user I do not have write
access to the Windows partitions that I have mounted. So I have
to be the superuser to be able to write to that partition. I
have created a simple shell script that copies my files to the
Windows partitions. This script was created by root user and
the SUID bit was set. Access rights to this script have been
given to all users. Now whenever I want to copy my files I simply
run this script. Even though I have logged in as a normal user,
the SUID bit which is set causes this script to execute as if
the root was executing it and it allows me to write to the Windows
partitions.
Had the SUID bit not been set, I would have to type ' su ' at
the prompt and get temporary superuser access to get write access
to the Windows partitions. Hope you got the point..
Note : In case
you do not know how to access your Windows partitions through
Linux, refer to
You may be thinking that since these applications would run
as root they can do harmful things and destroy the system. The
concept behind SUID bit is that you as the superuser would be
able to allow certain applications / scripts to be run by the
users as if they were the superuser for the time being. What
these application / scripts do when they execute should be completely
known to you. Even though the users would be allowed to execute
these programs as root they would be able to do ONLY THOSE
things that these programs were designed to do. So in case
a script was designed to copy 5 files from one place to another.
Then the user who would run that script would be able to ONLY
copy those 5 files from one place to another. He would not be
able to modify that script in any way since he would not
have write access to the script. He would only be having
execute rights for that script. Hence its an excellent idea
to allow users to do some important backup using a script that
does only that and by setting the SUID bit for that script.
This way the users don't have to know the superuser password
but can still use some facilities that are only available to
the superuser
Important
: Think twice before setting the SUID bit for scripts (owned
by root) that take arguments at the command line. Since you
never know what parameters a malicious user may pass to your
script. Since the script would run as root it could do great
damage if misused.
SGID (Set Group ID) bit
Just like SUID, setting the SGID bit for a file sets your group
ID to the file's group while the file is executing. IT is really
useful in case you have a real multi-user setup where users
access each others files. As a single homeuser I haven't really
found a lot of use for SGID. But the basic concept is the same
as the SUID, the files whose SGID bit are set would be used
as if they belong to that group rather than to that user alone.
Note
: Making SUID and SGID programs completely safe is very
difficult (or maybe impossible) thus in case you are a system
administrator it is best to consult some professionals before
giving access rights to root owned applications by setting
the SUID bit. As a home user (where you are both the normal
user and the superuser) the SUID bit helps you do a lot of things
easily without having to log in as the superuser every now and
then.
