In deploying to a new (Solaris 9) environment recently, one of the steps was to copy a set of files and directories to their new location and then to apply the group UID bit (us
Here is very handy explanation of SGID (chmod g+s): http://www.linuxnix.com/sgid-set-sgid-linuxunix/
SGID (Set Group ID up on execution) is a special type of file permissions given to a file/folder. Normally in Linux/Unix when a program runs, it inherits access permissions from the logged in user. SGID is defined as giving temporary permissions to a user to run a program/file with the permissions of the file group permissions to become member of that group to execute the file. In simple words users will get file Group’s permissions when executing a Folder/file/program/command.
For a executable, g+s
overrides the group id that the executable will run as (it is usually inherited from the parent).
$ cp `which id` id-test $ ./id-test uid=1001(user1) gid=1001(group1) groups=1001(group1),2001(project1) $ chgrp project1 id-test $ chmod g+s id-test $ ./id-test uid=1001(user1) gid=1001(group1) egid=2001(project1) groups=1001(group1),2001(project1)
(egid is "effective group id" -- usually the same as gid, "group id", but here different.)
For a directory, g+s
overrides the group id that new files and directories will have (it is usually inherited from the creator).
$ mkdir project $ chgrp project1 file1 $ umask 0022 $ touch project/file1 $ ls -l project/file1 -rw-r--r-- 1 user1 group1 0 file1 $ chmod g+s project $ touch project/file2 $ ls -l project/file2 -rw-r--r-- 1 user1 project1 0 file2
You may still need to fiddle with umask
for best results; something at least as permissive as 0007
is required for shared writing, and something at least as permissive as 0027
is required for shared reading.
$ umask 0077 $ touch project/file3 $ ls -l project/file3 -rw------- 1 user1 project1 0 file3 $ umask 0027 $ touch project/file4 $ ls -l project/file4 -rw-r----- 1 user1 project1 0 file4 $ umask 0007 $ touch project1/file5 $ ls -l project1/file5 -rw-rw---- 1 user1 project1 0 file5
For files it means that the file is executed as the group that owns the file, not the group user that executes the file belongs to. It is usable when you want to allow user to do something which for which he does not have the privilege. For example, for one DBMS I use, it is common to allow everybody to backup databases. Although only the 'dbms' group has read/write access to database file, the backup program has g+s set to allow anyone to access the database through it, but not directly.
For directories, it means that newly created directories will be owned by the group that owns the directory, not the group user that created the file belongs to. A good example for this is web space of sourceforge.net project. Imagine 3 developers maintaining the project website. Now, if one of them creates a file, only he can write to it (by default). To work around this, all users on the same project are in the same group as well, and directory has rws privilege for that group, so whoever creates the file, it gets created as readable and writable to the group.
When you need to use it: Fix SVN file ownership issue when you use svn+ssh. Somebody told me it only happens on BDB, but I had such issue in FSFS storage too. Basically when you want to keep the ownership of child files inside a directory consistent when there are other users writing stuff on it, you would have to use u+s/g+s.
For executable files, this means that when the file is executed, it is executed as the group that owns the file, not the group of the user executing the file.
This is useful if you want users to be able to assume the permissions of a particular group just for running one command.
However, it is also a security risk as it is allowing users to elevate their permissions. You have to know that the scripts with this bit set aren't going to do anything that would let users abuse these extra permissions.
More information about setuid and setgid here