Почему setuid игнорируется в каталогах?

В системах Linux вы можете успешно chmod u+s $some_directory, но вместо того, чтобы принудительно владеть новыми подкаталогами и файлами в качестве владельца содержащего каталога (и также устанавливать подкаталоги u+s), как и следовало ожидать, система просто игнорирует бит setuid. Подкаталоги и файлы продолжают наследовать UID их процессов создания, а подкаталоги по умолчанию не установлены.

Почему setuid игнорируется в каталогах, и как я могу заставить систему распознавать это?

Напомним, что биты setuid и setgid были изобретены для совершенно другой цели: запуск исполняемого файла с использованием uid или gid его владельца, а не uid или gid пользователя, выполняющего файл. Любое другое использование - это просто дополнительная функция.

Эти биты не работают с обычными файлами, которые не являются исполняемыми. (А также сценарии оболочки в некоторых дистрибутивах из-за проблем безопасности.) Изначально они также не имели функции для каталогов. Очевидно, кто-то решил, что было бы здорово взять неиспользуемый setgid для каталогов и использовать его для обеспечения согласованности владения группой. В конце концов, если вы играете с групповым владением, это потому, что с файлом работает более одного человека, и, вероятно, имеет смысл, чтобы все файлы в данном каталоге принадлежали к одной группе, независимо от того, кто их создал. Беспокойство из-за того, что кто-то забыл запустить newgrp, устранено.

Итак, почему бы не реализовать одну и ту же функцию для setuid и uid файла? Ну, UID гораздо более простой, чем GID. Если вы реализуете это, часто файл не будет принадлежать пользователю, который его создал! Предположительно, пользователь все еще может изменить файл (предполагая, что umask - что-то вменяемое), но он не может изменить биты прав доступа. Трудно увидеть полезность этого.

Я считаю, что ответ на этот вопрос связан с проблемами безопасности «раздачи файлов», которые привели к тому, что большинство современных Unix-подобных ОС не разрешают «раздачу файлов». «Раздача файлов» - это когда пользователь, не являющийся суперпользователем, меняет владельца файла на кого-то, кроме этого пользователя. Эта возможность предоставляет много возможностей для вреда.

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

Что касается изменения поведения, вам придется изменить библиотеки ОС и утилиты.

Один очень хороший вариант использования для реализации этого:

Допустим, у вас есть многосайтовый сервер с 3 защищенными сайтами. Вы создали 3 группы, по одной для каждого из сопровождающих сайтов. Все файлы на всех сайтах должны принадлежать пользователю apache, чтобы apache мог читать и записывать их (drupal / wordpress и т. Д.).

Если setuid, но работает как бит setgid для прав доступа к каталогам, будет выглядеть примерно так:

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

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

Другой вариант использования - для анонимных загрузок по ftp / http или даже по sftp / ssh. Группа и GID в каталоге загрузки будут корневыми, как и владелец и UID. Другие разрешения будут -wx. Это позволило бы всем ЗАПИСАТЬ доступ к каталогу загрузки, но они не могли ничего читать, после того как он был загружен, и root будет владеть всеми вновь созданными файлами.

Таким образом, есть два совершенно хороших и правильных варианта использования для включения функциональности UID в каталогах, чтобы соответствовать биту GID.

Стивен Меркурио

Немного опоздал на вечеринку, но в случае, если будущие читатели столкнутся с этим;) Как утверждают другие, в стандартной файловой системе OS-X setUID для каталогов игнорируется - и кажется, что не существует простого способа обойти это ( mount -o.... или что нет). Как это часто бывает, справочная страница фактически не соответствует поведению OS-X, в котором она буквально заявляет:

4000 (бит set-user-ID-on-execute) [...] Каталоги с установленным битом set-user-id заставят все файлы и подкаталоги, созданные в них, принадлежать владельцу каталога, а не UID процесса создания [...]

но он также перечисляет возможность достижения того же эффекта, не отказываясь от первоначальной собственности. Linux использует '[g /] setfacls' для похожих эффектов (на первый взгляд они не видны, поэтому иногда могут быть неприятны).

Что касается того, «как я могу добиться подобных эффектов», прочитайте всю справочную страницу и поиграйте с:

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

вы можете проверить через

ls -le

если все выглядит хорошо. Дополнительные параметры включают вставку правил в определенные позиции, удаление или замену определенных правил. Два заслуживающих внимания варианта здесь " file_inheritиdirectory_inherit », позволяющих присоединить правила к новому каталогу / файлу.

Я не очень люблю использовать setUID, но setGID очень удобен на файловых серверах, где просто установка основной группы не работает, или у клиентов есть файловые маски, запрещающие запись группы. Это будет решено путем:

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

Ну, это должно уважать стандарт. На многих сценариях с sftp-only я могу думать, что это избавит меня от многих проблем, как с acl, так и с набором acl-mask-set, который делает sshd, и сбросом, который я должен сделать с этой маской.

Безопасность по умолчанию довольно полезна, но если вы не сделаете это опцией, вы просто создаете winghtmare.

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

В любом случае, сейчас всё как в Linux, так что просто используйте acl для их обхода.

Согласно http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories, бит setuid игнорируется для каталогов в системах UNIX и Linux. Однако можно заставить его работать так, как вы ожидаете от FreeBSD.