"Taking a LiveFire Labs' course is an excellent way to learn
Linux/Unix. The lessons are well thought out, the material is
explained thoroughly, and you get to perform exercises on a real
Linux/Unix box. It was money well spent."
Ray S.
Pembrook Pines, Florida
LiveFire Labs' UNIX and Linux Operating System Fundamentals
course was very enjoyable. Although I regularly used UNIX systems
for 16 years, I haven't done so since 2000. This course was a
great refresher. The exercises were fun and helped me gain a real
feel for working with UNIX/Linux OS. Thanks very much!"
Ming Sabourin
Senior Technical Writer
Nuance Communications, Inc.
Montréal, Canada
Read more student testimonials...
Receive UNIX Tips, Tricks, and Shell Scripts by Email
LiveFire Labs' UNIX Tip,
Trick, or Shell Script of the Week
Special Purpose Access Modes (Permissions) - Part II - SGID (set
group ID)
This week's tip on SGID is the second installment in a series
on special purpose access modes that will culminate with next week's
tip about the sticky bit. SGID, or set group ID, is similar to SUID (
last week's tip) in one way
but different in another.
You may recall from last week that when the SUID bit is set on an
executable file (command), the process running that command will
inherit the privileges and access rights of the file's owner for its
duration, not those of the user who created the process. The UNIX
command that was used to illustrate this concept was passwd:
-r-sr-sr-x 3 root sys 73748 Nov 2 2001
/usr/bin/passwd
Similar to SUID, SGID also grants privileges and access rights to the
process running the command, but instead of receiving those of the
file's owner it receives those of the file's group. In other words,
the process group owner will be set to the file's group. From the ls
output above, you know the SGID bit is set because of the "s" in the
third position of the group permission set.
When SGID is set on a directory it has a special meaning. Files
created in a directory with SGID set will inherit the same group
ownership as the directory itself, not the group of the user who
created the file.
Consider the primary gid for the livefire user account, whose present
working directory (PWD) is /project1:
$ who
livefire console Sep 11 21:01
$ id -a
uid=100(livefire) gid=1(other) groups=1(other),100(support)
$ pwd
/project1
$ ls -ld ../project1
drwxrwx--- 2 root support 512 Sep 11 20:55 ../project1
You can see from this output that the group owner for project1 is
support, and that the SGID bit has not been set on the directory yet.
When livefire creates a file in project1, the group for the file is
other (livefire's primary gid):
$ touch file1
$ ls -l file1
-rw-r--r-- 1 livefire other 0 Sep 11 20:56 file1
After root sets SGID on project1 using the chmod command, files
created by livefire inherit the directory's group (support in this
example):
commands performed by root...
[root@hawk] # chmod g+s project1
[root@hawk] # ls -ld project1
drwxrws--- 2 root support 512 Sep 11 20:56 project1
commands performed by livefire...
$ pwd
/project1
$ touch file2
$ ls -l
total 0
-rw-r--r-- 1 livefire other 0 Sep 11 20:56 file1
-rw-r--r-- 1 livefire support 0 Sep 11 21:00 file2
* Notice the group ownership for file2
Enabling SGID on a directory is extremely useful when you have a group
of users with different primary groups working on the same set of
files.
Read the PREV article in this series -
Special Purpose
Access Modes (Permissions) - Part I - SUID (set user ID)
Read the NEXT article in this series - Special Purpose Access Modes
(Permissions) - Part III - The Sticky Bit