Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Setgid bit in directories

News Access Control in Operating Systems Recommended Links The umask SUID/SGID attributes Sticky attribute (sticky bit) in Unix File Permissions Hardening
World writable files problem SUID/SGID Checkers Unix History Groups administration Admin Horror Stories Humor Etc

The setgid bit in directories has a special meaning in BSD Unix, and this behavior is now emulated by Solaris and most other commercial and free Unixes. When a directory has setgid on, files written by a user in that directory will have the same group owner as the directory, rather than the primary group of the user.  In this case  writable directories that belong to any system group are very dangerous (you can set sgid bit on the directory and create a file that will be owned by a group  and generally it should not be used with world writable directories. 

Note: NFS can mount filesystem with the option "grpid". This will cause all directories to always have the setgid bit set.

If you set the setgid bit on a directory (with chmod g+s directory), files created in that directory will have their group set to the directory's group. This is a very elegant way to enforce the necessary group on subtree. Most IT organizations like to create a group for each major project and assign people to the groups they should be in. Managing access to files created by various applications traditionally has been a difficult task in Unix.  When someone creates a file it is owned by the primary group he or she belongs to. When a single person works on multiple projects, it becomes hard to associate the right files to the right ownership group. Here setgid bit came into play.

Let's say you have a big project called SGE_cluster for which sge group was created and we need that all files, which are located in a /srv/SGE_cluster  directory be editable by all members of SGE_cluster project.  Make a group called sge and assign it to the directory. Now assign setgid to /srv/SGE_cluster directory and add all members working on the project to the sge  group. Change permission for existing files to 775. From this point, users belonging to the  sge group will be able to edit the files and create new files in the /srv/SGE_cluster  directory. New files created by any member of the sge group will belong to the sge  group, not to the primary group of the particular user. 

If you have multiple projects and users who are working on multiple projects, these users will never have to change their umask or primary group when they move from project to project. The setgid bit on each project's main directory "selects" the proper group.

In ls listing such group is marked by letter s in execute position. The designator letter is capitalized if the bit is set, and the corresponding execute bit is not set. Otherwise lower case "s" is displayed. Thus, a directory that has its sticky and SGID bits set, and is otherwise mode 775, would appear in an ls listing as

ls -l /srv/SGE_cluster 
drwxrwsr-x 2 root sge 4096 Jun 2 21:08 /srv/SGE_cluster

Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Jun 02, 2014] Directory Setuid and Setgid

GNU Coreutils

On most systems, if a directory's set-group-ID bit is set, newly created subfiles inherit the same group as the directory, and newly created subdirectories inherit the set-group-ID bit of the parent directory. On a few systems, a directory's set-user-ID bit has a similar effect on the ownership of new subfiles and the set-user-ID bits of new subdirectories. These mechanisms let users share files more easily, by lessening the need to use chmod or chown to share new files.

These convenience mechanisms rely on the set-user-ID and set-group-ID bits of directories. If commands like chmod and mkdir routinely cleared these bits on directories, the mechanisms would be less convenient and it would be harder to share files. Therefore, a command like chmod does not affect the set-user-ID or set-group-ID bits of a directory unless the user specifically mentions them in a symbolic mode, or sets them in a numeric mode. For example, on systems that support set-group-ID inheritance:

     # These commands leave the set-user-ID and
     # set-group-ID bits of the subdirectories alone,
     # so that they retain their default values.
     mkdir A B C
     chmod 755 A
     chmod 0755 B
     chmod u=rwx,go=rx C
     mkdir -m 755 D
     mkdir -m 0755 E
     mkdir -m u=rwx,go=rx F

If you want to try to set these bits, you must mention them explicitly in the symbolic or numeric modes, e.g.:

     # These commands try to set the set-user-ID
     # and set-group-ID bits of the subdirectories.
     mkdir G H
     chmod 6755 G
     chmod u=rwx,go=rx,a+s H
     mkdir -m 6755 I
     mkdir -m u=rwx,go=rx,a+s J

If you want to try to clear these bits, you must mention them explicitly in a symbolic mode, e.g.:

     # This command tries to clear the set-user-ID
     # and set-group-ID bits of the directory D.
     chmod a-s D

This behavior is a GNU extension. Portable scripts should not rely on requests to set or clear these bits on directories, as POSIX allows implementations to ignore these requests.

[Chapter 22] 22.5 Group Permissions in a Directory with the setgid Bit

If you work on a UNIX system with lots of users, you may be taking advantage of UNIX group permissions ( 22.2 ) to let users in one group write to files in a directory - but not let people in other groups write there.

How does UNIX determine what group should own the files you create? There are three ways:

  1. On most System V-based systems, the effective group ID of the process determines the ownership of the files you create. (Your effective GID is your primary group membership ( 22.13 ) unless you're running a SGID ( 1.23 ) program.)

  2. On most BSD UNIXes, files are owned by the group that owns the directory in which you create the file .

  3. The rules under SunOS 4. x and System V Release 4 are more complicated. The system administrator decides which of the two above methods a filesystem will use for group ownership. There are other wrinkles, too. A good place to look for the gory details is your system's open (2) manpage... but it's probably easier to just create an empty new file ( 21.7 ) and then check the group ownership with ls -l or -lg ( 22.2 ) .

    You may be able to use the directory's set group ID (setgid) bit to control group ownership. In those cases, if the bit is set, the BSD rules apply. if the bit is not set, the System V rules apply. To set and remove the setgid bit, use the commands chmod g+s ( 22.7 ) and chmod g-s , respectively.

You can use the chgrp ( 1.23 ) command to change a file's group. However, you must own the file. And you must also be a member of the file's new group.

If you've reset directory mode bits, it's possible to wind up with ls -l permissions that have an uppercase "S", like drwxr-S-- . What's that? (It's often a mistake.) The directory's setgid bit is set, but the execute bit isn't set. If you want the directory to be group-accessible, add execute permission with chmod g+x . Otherwise, you may want to clear the setgid bit with chmod g-s .

Recommended Links

Sticky bit - Wikipedia, the free encyclopedia



Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: June 02, 2014