Когда можно или нужно использовать chmod g+s для файла или каталога?
При недавнем развертывании в новой среде (Solaris 9) одним из шагов было скопировать набор файлов и каталогов в их новое расположение, а затем применить бит UID группы (используя "chmod -R g+s") ко всем файлы в дереве каталогов, дающие режим -rwxr-s --- для всего. В результате ни один из наших сценариев оболочки не был бы выполнен, если бы они не были по отдельности открыты и повторно сохранены. Я должен добавить, что мы ранее установили g + s в целевой родительской папке до копирования файлов; это установило начальный режим для всех новых каталогов на drwxr-s ---, но файлы имели режим -rwxr-x ---
В конце концов обнаружив, какой шаг вызвал проблему, мы смогли вырезать этот шаг и продолжить.
Однако я хотел бы понять, что означает бит "s" применительно к каталогам и файлам, в надежде, что это объяснит, почему у нас возникла проблема в первую очередь.
8 ответов
При установке каталогов g+s все новые файлы, созданные в указанном каталоге, получают группу, равную группе каталога.
На самом деле это может быть очень удобно для совместной работы, если у вас установлен umask, чтобы файлы по умолчанию записывались в группы.
Примечание. В Linux это работает так же, как и в Solaris.
Для исполняемых файлов это означает, что когда файл исполняется, он исполняется как группа, которой принадлежит файл, а не как группа пользователя, исполняющего файл.
Это полезно, если вы хотите, чтобы пользователи могли принимать разрешения определенной группы только для запуска одной команды.
Тем не менее, это также риск для безопасности, поскольку он позволяет пользователям повысить свои разрешения. Вы должны знать, что сценарии с этим набором битов не будут делать ничего, что позволило бы пользователям злоупотреблять этими дополнительными разрешениями.
Вот очень удобное объяснение SGID (chmod g + s): http://www.linuxnix.com/sgid-set-sgid-linuxunix/
SGID (установка идентификатора группы при выполнении) - это особый тип прав доступа к файлу, который предоставляется файлу / папке. Обычно в Linux / Unix при запуске программы она наследует права доступа от вошедшего в систему пользователя. SGID определяется как предоставление временных разрешений пользователю для запуска программы / файла с разрешениями разрешений файловой группы, чтобы стать членом этой группы для выполнения файла. Проще говоря, пользователи получат права доступа группы файлов при выполнении команды Папка / файл / программа /.
Для исполняемого файла g+s переопределяет идентификатор группы, под которой будет выполняться исполняемый файл (обычно он наследуется от родительского).
$ cp `which id` id-test $ ./id-test uid=1001(пользователь1) gid=1001(группа1) groups=1001(группа1),2001(проект1) $ chgrp project1 id-test $ chmod g+s id-тест $ ./id-test uid=1001(пользователь1) gid=1001(группа1) egid=2001(проект1) groups=1001(группа1),2001(проект1)
(egid - "эффективный идентификатор группы" - обычно такой же, как gid, "идентификатор группы", но здесь другой.)
Для каталога, g+s переопределяет идентификатор группы, который будут иметь новые файлы и каталоги (обычно он наследуется от создателя).
проект $ mkdir $ chgrp project1 file1 $ umask 0022 $ touch project/file1 $ ls -l project/file1 -rw-r- r-- 1 пользователь1 группа1 0 файл1 проект $ chmod g + s $ touch project/file2 $ ls -l project/file2 -rw-r- r-- 1 пользователь1 проект1 0 файл2
Возможно, вам все равно придется возиться с umask для лучших результатов; что-то, по крайней мере, столь же разрешающее, как 0007 требуется для совместного написания, и что-то по крайней мере столь же разрешающее, как 0027 требуется для совместного чтения.
$ umask 0077 $ touch project / file3 $ ls -l project / file3 -rw ------- 1 пользователь1 проект1 0 файл3 $ umask 0027 $ touch project/file4 $ ls -l project/file4 -rw-r----- 1 пользователь1 проект1 0 файл4 $ umask 0007 $ touch project1/file5 $ ls -l project1/file5 -rw-rw---- 1 пользователь1 проект1 0 файл5
Для файлов это означает, что файл выполняется как группа, которой принадлежит файл, а не как пользователь группы, которому исполняется файл. Это полезно, когда вы хотите разрешить пользователю делать то, на что у него нет привилегии. Например, для одной СУБД, которую я использую, принято разрешать всем делать резервные копии баз данных. Хотя только группа 'dbms' имеет доступ для чтения / записи к файлу базы данных, программа резервного копирования имеет набор g+s, позволяющий любому получить доступ к базе данных через нее, но не напрямую.
Для каталогов это означает, что вновь созданные каталоги будут принадлежать группе, которой принадлежит каталог, а не пользователю группы, к которой принадлежит файл. Хорошим примером для этого является веб-пространство проекта sourceforge.net. Представьте, что 3 разработчика поддерживают сайт проекта. Теперь, если один из них создает файл, только он может писать в него (по умолчанию). Чтобы обойти это, все пользователи в одном и том же проекте также находятся в одной группе, и каталог имеет привилегию rws для этой группы, поэтому, кто бы ни создавал файл, он создается как читаемый и доступный для записи группе.
Чтобы немного расширить вашу конкретную проблему, уже было отмечено, что исполняемые файлы sgid могут вызывать проблемы, предоставляя пользователям разрешения, которых у них обычно нет. Хотя это проблема для любого исполняемого файла, в случае сценариев он создает потенциально эксплуатируемое состояние гонки (в частности, "файлы, которые выполняются с помощью внешнего интерпретатора, обозначенного символом #! В начале файла"), который может использоваться для выполнения любого произвольного кода с разрешениями скрипта.
Производные Unix за последние годы внедрили ряд схем, направленных на смягчение или устранение этой уязвимости, большинство из которых включало некоторую форму полного запрещения выполнения сценариев suid или sgid или требовали, чтобы вы включили несколько циклов, чтобы включить его. (обычно по сценарию за сценарием). Одна из таких схем может стать причиной невозможности запуска сценариев после включения их флага sgid.
Когда вам нужно его использовать: Исправьте проблему владения SVN-файлом при использовании svn+ssh. Кто-то сказал мне, что это происходит только на BDB, но у меня тоже была такая проблема с хранилищем FSFS. В основном, если вы хотите, чтобы владение дочерними файлами внутри каталога было согласованным, когда другие пользователи пишут что-либо, вы должны использовать u+s/g+s.