Когда можно или нужно использовать chmod g + s для файла или каталога?

Для исполняемых файлов это означает, что когда файл выполняется, он выполняется как группа, владеющая файлом, а не группа пользователя, выполняющего файл.

Это полезно, если вы хотите, чтобы пользователи могли принимать разрешения определенной группы только для выполнения одной команды.

Однако это также угроза безопасности, поскольку позволяет пользователям повышать свои разрешения. Вы должны знать, что сценарии с этим набором битов не будут делать ничего, что позволило бы пользователям злоупотреблять этими дополнительными разрешениями.

Подробнее о setuid и setgid здесь

Установка каталогов g + s заставляет все новые файлы, созданные в указанном каталоге, иметь группу, установленную на группу каталога.

Это действительно может быть очень удобно для совместной работы, если у вас установлена ​​маска umask, чтобы файлы по умолчанию имели групповую запись.

Примечание. Это работает в Linux так, как в Solaris.

Для файлов это означает, что файл выполняется от имени группы, которой принадлежит файл, а не от группы, которой принадлежит пользователь, выполняющий файл. Его можно использовать, когда вы хотите разрешить пользователю делать что-то, на что у него нет прав. Например, для одной СУБД, которую я использую, принято позволять всем создавать резервные копии баз данных. Хотя только группа «dbms» имеет доступ для чтения / записи к файлу базы данных, программа резервного копирования имеет настройки g + s, позволяющие любому получить доступ к базе данных через нее, но не напрямую.

Для каталогов это означает, что вновь созданные каталоги будут принадлежать группе, которой принадлежит каталог, а не группе, которой принадлежит пользователь, создавший файл. Хорошим примером этого является веб-пространство проекта sourceforge.net. Представьте, что 3 разработчика поддерживают сайт проекта. Теперь, если один из них создает файл, только он может писать в него (по умолчанию). Чтобы обойти это, все пользователи в одном проекте также находятся в одной группе, а каталог имеет привилегию rws для этой группы, поэтому, кто бы ни создал файл, он будет создан как доступный для чтения и записи для группы.

Для исполняемого файла g+s переопределяет идентификатор группы, от имени которой исполняемый файл будет запускаться (обычно он наследуется от родительского).

$ 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 - это «эффективный идентификатор группы» - обычно то же самое, что и gid, «идентификатор группы», но здесь другой.)

Для каталога g+s переопределяет идентификатор группы, который будет иметь новые файлы и каталоги (обычно он наследуется от создателя).

$ 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

Возможно, вам все равно придется повозиться с umask для достижения наилучших результатов; что-то, по крайней мере, столь же разрешительное, как 0007, требуется для совместной записи, и что-то, по крайней мере, столь же разрешительное, как 0027, требуется для совместного чтения.

$ 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

Чтобы немного расширить вашу конкретную проблему, уже было отмечено, что исполняемые файлы sgid могут вызывать проблемы, предоставляя пользователям разрешения, которых у них обычно нет. Хотя это проблема для любого исполняемого файла, она создает потенциально возможное состояние гонки в случае сценариев (в частности, имея в виду «файлы, которые выполняются с помощью внешнего интерпретатора, обозначенного знаком #! В начале файла»), что может использоваться для выполнения любого произвольного кода с разрешениями сценария.

Производные Unix за прошедшие годы реализовали ряд схем, направленных на смягчение или устранение этой уязвимости, большинство из которых включают в себя некоторую форму полного запрета выполнения сценариев suid или sgid или требования, чтобы вы перепрыгнули через несколько обручей, чтобы включить ее. (обычно от сценария к сценарию). Одна из таких схем может быть причиной вашей неспособности запускать скрипты после включения их флага sgid.

Когда вам нужно его использовать: Устраните проблему владения файлом SVN при использовании svn + ssh. Кто-то сказал мне, что это происходит только на BDB, но у меня тоже была такая проблема в хранилище FSFS. В основном, когда вы хотите сохранить права собственности на дочерние файлы внутри каталога, когда есть другие пользователи, которые пишут в нем что-то, вам придется использовать u + s / g + s.

Вот очень удобное объяснение 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.