Now setuid and setgid

Now setuid and setgid

Sometimes, unprivileged users must be able to accomplish tasks that require
privileges. An example is the passwd program, which allows you to change your
password. Changing a user's password requires modifying the password field in the
/etc/passwd file. However, you should not give a user access to change this file
directly- the user could change everybody else's password as well! Likewise, the mail
program requires that you be able to insert a message into the mailbox of another
user, yet you should not to give one user unrestricted access to another's mailbox.
To get around these problems, linux allows programs to be implemented with special
privileges. Processes executing these programs can assume another UID or GID

when they're running. A program that changes its UID is called a SUID program (set-
UID); a program that changes its GID is called a SGID program (set-GID). A
program can be both SUID and SGID at the same time.
When a SUID program is run, its effective UID becomes that of the owner of the file,
rather than of the user who is running it.
If setuid permission is applied on a file like :
[root@mainserver / ]# chmod 4511 myprogram.sh
then myprogram.sh has the ownership and permissions as :
-r-s--x--x 1 root admin 16336 Feb 14 2003 myprogram.sh
,then this means that whenever any user, like kamran logs on to the system and runs
this program then this program is run as not user kamran but user root !!!!. The “ s ”
in the owner's permission set indicates that this file has setuid bit on.
If setgid permission is applied on a file like :
[root@mainserver / ]# chmod 2711 myprogram.sh
then myprogram.sh has the ownership and permissions as :
-rwx--s--x 1 root admin 16336 Feb 14 2003 myprogram.sh
,then this means that any process that executes this SGID program has its effective
GID changed to the program's GID (admin in this case). Files created by the process
can have their primary group set to this GID as well, depending on the permissions of
the directory in which the files are created. The “ s ”in the group permission set
indicates that this file has setgid bit on.
The setgid bit is normally useful on directories. For example you have a directory
named newproject and it has ownership as root:students and permissions like:


[root@mainserver / ]# chmod 2770 myprogram.sh
[root@mainserver / ]# ls -l
drwxrws--- 2 root students 4096 Jul 13 21:38 newproject
This means that any user who creates an object within this directory will effectively
create that object with students in the group ownership.
In other words, the SGID bit on a directory controls the way that groups are assigned
for files created in the directory. If the SGID bit is set, files created in the directory
have the same group as the directory if the process creating the file also is in that
group. Otherwise, if the SGID bit is not set, or if the process is not in the same group,
files created inside the directory have the same group as the user's effective group ID
(usually the primary group ID).
Setuid and setgid can be security risk you can find files which have setuid and setgid
set on them by:
[root@mainserver / ]# find / \(-perm -004000 -o -perm -002000 \)
 -type f -print
This find command starts in the root directory (/) and looks for all files that match
mode 002000 (SGID) or mode 004000 (SUID). The -type f option causes the search
to be restricted to files. The -print option causes the name of every matching file to
be printed.
Note that if you are using NFS, you should execute find commands only on your file
servers. You should further restrict the find command so that it does not try to search
networked disks. Otherwise, use of this command may cause an excessive amount of
NFS traffic on your network. To restrict your find command, use the following:
[root@mainserver / ]# find / \( -local -o -prune \)
 \( -perm -004000 -o -perm -002000 \) type f -print