В системах 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 заставят все файлы и подкаталоги, созданные в них, принадлежать владельцу каталога, а не 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.