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

19

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

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

Черный свет
источник
Интересно, может ли опция монтирования nosuid повлиять на это?
Гепт
Файловая система, о которой идет речь, не смонтирована, nosuidхотя есть и другая (ramdisk /dev/shm), которая / is / mount nosuid, и кажется, что она обрабатывает setuidбит точно так же. 6_9
Сияющий
1
Смотрите также: serverfault.com/questions/371541/…
jjlin
2
Что касается его реализации, исходный код Linux легко доступен, не стесняйтесь реализовать эту функцию. Поскольку он уже существует во FreeBSD, я уверен, что вы можете легко скопировать код поверх него. Конечно, эти биты все равно не будут иметь никакого значения в чьей-либо системе Linux.
Майкбабкок

Ответы:

16

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

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

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

Исаак Рабинович
источник
Я хотел бы, чтобы это было реализовано, хотя бы ради согласованности ... X3 В любом случае, если не считать обходного пути, такого как cronjob, для периодического прохождения и смены владельца, / есть / есть ли способ заставить владельца файла?
Blacklight Shining
4
У меня возникает соблазн процитировать Эмерсона в «Глупой последовательности». Прежде чем вы сможете убедить меня в том, что это полезная функция, вам нужно будет показать пример использования, в котором она имеет смысл.
Исаак Рабинович
1
FreeBSD chmod (2) фактически обсуждает это, но упоминает только, что его вообще не следует использовать из-за неуказанных «дыр в безопасности». Я подозреваю , что большинство других Unixes не принять эту функцию , потому что в то время как у него есть некоторые случаи использования, это не что очень полезно.
jjlin
1
«Трудно увидеть полезность этого» -> установлено в домашнем каталоге, поэтому сценарии инициализации, работающие от имени пользователя root, не могут забыть что-то случайно?
ufotds
1
запускать сценарии суперпользователя в вашем домашнем каталоге - очень плохая идея
Исаак Рабинович
7

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

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

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

Yedric
источник
2

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

Допустим, у вас есть многосайтовый сервер с 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.

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

user297422
источник
1
Похоже, это не решает вопрос, который был задан.
Кевин Панко
2
@KevinPanko Нет, это не отвечает на мой вопрос. Это может быть даже не по теме для сайта («для чего нужен вариант <nonexistent feature X>?»). Тем не менее, это относится к моему вопросу, и я, как спрашивающий, считаю его полезным.
Blacklight Shining
0

Немного опоздал на вечеринку, но в случае, если будущие читатели столкнутся с этим;) Как утверждают другие, в стандартной файловой системе 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
Кит
источник
Добро пожаловать в Stack Exchange! Это хороший ответ, хотя, поскольку он относится к OS X, а не к дистрибутивам Linux (которые, как вы упомянули, используют другую систему ACL), он здесь не совсем уместен. Это определенно подойдет для вопроса о том, как сделать OS X соблюдающими каталоги setuid; может быть, вы должны опубликовать один ?
Blacklight Shining
Кстати, часть, которую вы пропустили на странице руководства по OS X, на chownсамом деле кажется довольно важной! «[…] Если базовая файловая система поддерживает эту функцию: см. Chmod (2) и параметр suiddir для монтирования (8)». На самом деле я никогда раньше не замечал этого. Если HFS реализует suiddir, вы можете добиться этого в обычной системе OS X.
Blacklight Shining
(А списки ACL для OS X так же «не видны на первый взгляд», как ACL для Linux.)
Blacklight Shining
0

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

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

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

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

user576407
источник
-1

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

Бэбкок
источник
Бесполезно - я спросил, почему setuidигнорировали каталоги и можно ли было сделать его узнаваемым в Linux.
Blacklight Shining
Кажется очевидным, что он игнорируется в Linux, потому что игнорируется в Unix, что делает его правильным для Linux, чтобы соответствовать настоящему * nix. Не стесняйтесь читать данную статью. Тот же ответ на greenend.org.uk/rjk/tech/perms.html от 2004 года, также дубликат serverfault.com/questions/371541/…
mikebabcock
Так почему же это игнорируется в Unix?
Исаак Рабинович
@IsaacRabinovitch, поскольку Blacklight ясно дал понять, что вопрос касается Linux, он не имеет отношения к делу, но я подозреваю, что его просто неопределенное поведение, когда несколько Unix-ов делали разные вещи и ничего не делали, является более безопасным предположением.
Майкбабкок
Вопрос / помечен / помечен linux, да, но это не значит, что я предпочитаю расплывчатое «Это сделано так, потому что другие системы делают это так», ответ на ответ, который объясняет, почему это делается в других системах. (Может быть, linuxтег должен быть просто удален?)
Blacklight Shining