When could or should I use chmod g+s on a file or directory?

Question

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 (using "chmod -R g+s") to all files in the directory tree giving a mode of -rwxr-s--- to everything. The result was that none of our shell scripts would execute unless they were individually opened and re-saved. I should add that we had earlier set g+s on the target parent folder prior to copying files; this had set the initial mode on all the new directories to drwxr-s--- but the files had a mode of -rwxr-x---

Having eventually discovered which step caused the problem, we were able to cut out that step and proceed.

I would like, however, to understand what the "s" bit means when applied to directories and files, in the hope that this will explain why we had the problem in the first place.

Answer 1

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.

Answer 2

More information about setuid and setgid here

Answer 3

Setting directories g+s makes all new files created in said directory have their group set to the directory's group.

This can actually be really handy for collaborative purposes if you have the umask set so that files have group write by default.

Note: This is the way it works in Linux, it could work completely differently in Solaris.

Answer 4

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.

Answer 5

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

Answer 6

To expand on your specific problem a little, it has already been noted that sgid executables can cause problems by granting users permissions they don't normally have. While this is an issue for any executable, it creates a potentially-exploitable race condition in the case of scripts (specifically meaning "files which execute by means of an external interpreter identified by a #! at the beginning of the file") which can be used to execute any arbitrary code with the script's permissions.

Unix deriviatives have implemented a number of schemes over the years which are aimed at mitigating or eliminating this vulnerability, most of which have included some form of prohibiting the execution of suid or sgid scripts entirely or requiring you to jump through a few hoops to enable it (usually on a script-by-script basis). One such scheme would be the cause of your inability to run the scripts after turning on their sgid flag.

Answer 7

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.