LiveFire Labs: Online UNIX Training with Hands-on Internet Lab

"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

Custom Search

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
$ 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
$ 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