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

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

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

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

Ответ 1

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

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

Примечание. Это то, как он работает в Linux, он может работать совершенно по-другому в Solaris.

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

Для исполняемого файла 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, "id группы", но здесь разные.)

Для каталога 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

Ответ 5

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

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

Ответ 6

Дополнительная информация о setuid и setgid здесь

Ответ 7

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

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

Ответ 8

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