LiveFire Labs - Online UNIX Training - Company Logo


Online UNIX Training with Hands-on Internet Lab


"Eliminate the expense and inconvenience of classroom training without eliminating the classroom experience."

 


Home
Internet Lab
Console Access
Sample Course

Student Login


LiveFire Labs' UNIX Tip, Trick, or Shell Script of the Week - View


Questions? Call
1.888.843.1637 or send us email

September 15, 2003 - 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.


Learn more...
  

If you are new to the UNIX or Linux operating system and would like to learn more, you may want to consider registering for LiveFire Labs' UNIX and Linux Operating System Fundamentals online training course.

Our innovative hands-on training model allows you to learn UNIX by completing hands-on exercises on real servers in our Internet Lab.


More Tips...

· 
Popular UNIX Tips from the Past

spacer Box Border
 

Receive the UNIX Tip, Trick, or Shell Script of the Week by Email


First Name:


Email Address:






   1.888.843.1637

Home - Contact us - Company info - Privacy Statement   

 
©2002-2003 LiveFire Labs.  All rights reserved.
Linux® is a registered trademark of Linus Torvalds, author and developer of this public domain operating system.
UNIX® is a registered trademark of The Open Group in the United States and other countries.