Когда можно или нужно использовать chmod g + s для файла или каталога? - PullRequest
32 голосов
/ 10 октября 2008

При недавнем развертывании в новой среде (Solaris 9) одним из шагов было скопировать набор файлов и каталогов в их новое расположение, а затем применить бит UID группы (используя «chmod -R g + s»). ) ко всем файлам в дереве каталогов, предоставляя режим -rwxr-s --- всем. В результате ни один из наших сценариев оболочки не был бы выполнен, если бы они не были по отдельности открыты и повторно сохранены. Я должен добавить, что мы ранее установили g + s в целевой родительской папке до копирования файлов; это установило начальный режим для всех новых каталогов на drwxr-s ---, но файлы имели режим -rwxr-x ---

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

Я хотел бы, однако, понять, что означает бит "s" применительно к каталогам и файлам, в надежде, что это объяснит, почему у нас возникла проблема.

Ответы [ 8 ]

75 голосов
/ 10 октября 2008

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

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

Примечание. Так работает в Linux, в Solaris он может работать совершенно иначе.

12 голосов
/ 10 октября 2008

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

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

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

7 голосов
/ 20 марта 2012

Вот очень удобное объяснение SGID (chmod g + s): http://www.linuxnix.com/sgid-set-sgid-linuxunix/

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

4 голосов
/ 10 октября 2008

Для исполняемого файла 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
2 голосов
/ 10 октября 2008

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

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

0 голосов
/ 10 октября 2008

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

0 голосов
/ 10 октября 2008

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

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

0 голосов
/ 10 октября 2008

Больше информации о setuid и setgid здесь

...