объяснение по chown(1) POSIX spec

Question 1

TheПодсистема Microsoft Interix Unix (сейчас на пенсии)для ядра NT он обрабатывал разрешения пользователей и групп немного иначе, чем некоторые другие:

Информация о пользователях и группах хранится вБаза данных доступа к безопасности. И пользователи, и группы хранятся в одной и той же базе данных, но имена групп и пользователей должны быть уникальными; ни одна группа не может иметь имя пользователя и наоборот.(Эта база данных заменяет файлы /etc/passwdи /etc/groupsв UNIX.)Пользователи и группы создаются с использованием соответствующей методологии Windows.(Диспетчер пользователей, Пользователи и компьютеры Active Directory или Локальные пользователи и группы)или с помощью команды Win32 net user.(Примеры сценариев оболочки для создания и удаления пользователей включены в каталог /usr/examples/admin.)Пользователи могут принадлежать ко многим группам.

Вотнекоторыйболее конкретные выдержки из руководства:

В Windows владеть объектом может как пользователь, так и группа. Это отличается от UNIX, где объектом владеет только пользователь.

Windows идентифицирует всех пользователей и группы внутренне, используя идентификатор безопасности.(СИД). Алгоритм хеширования генерирует уникальные значения SID; никакие два пользователя или группы не будут иметь одинаковый SID.

Пользователи и группы, имеющие разрешение на доступ к объекту, идентифицируются по их SID. Все объекты, которые могут быть защищены Windows, имеют список дискреционного управления доступом (DACL), который состоит из отдельных записей, называемых записями управления доступом (ACE). ACE включает в себя два важных фрагмента информации: SID пользователя или группы и описание того, какой уровень доступа имеет отдельный пользователь или группа к объекту.

ЧГРП

...Измените идентификатор группы для файла... пользователь, вызывающий chgrp(1), должен принадлежать к указанной группе и быть владельцем файла или иметь соответствующие привилегии.

ЧАУН

...Операнды владельца и группы являются необязательными, однако один из них должен быть указан. Если указан операнд группы, ему должно предшествовать двоеточие (:).

Владелец может быть указан как числовым идентификатором пользователя, так и именем пользователя. Если имя пользователя также является числовым идентификатором пользователя, операнд используется как имя пользователя. Группа может быть как числовым идентификатором группы, так и именем группы. Если имя группы также является числовым идентификатором группы, операнд используется как имя группы.

По соображениям безопасности изменить права собственности на файл может только процесс с соответствующими привилегиями.

Как я понял, это означает, что если ваша учетная запись пользователя принадлежит к группе Windows с достаточными привилегиями для изменения разрешений файла, принадлежащего этой группе, то можно эффективно управлять chgrpэтим файлом вне контроля вашей учетной записи пользователя. Это означает меньший контроль, чем вы могли бы иметь с chownявными user:groupпараметрами. В этом контексте без возможности объявленияuser: и :groupвы никогда не смогли бы достичь тех же результатов, что и в противном случае.

Вот ссылкаподробному рассмотрению того, как Interix взаимодействует с ACL Windows, с акцентом на то, как эти знания могут быть применены к файловым системам Samba в других вариантах Unix.

Вот ссылкав настоящее времяустаревшийДокумент Solaris, описывающий настраиваемый параметр rstchown, который...

chown(2)Указывает , применяется ли семантика POSIX для системного вызова...

По-видимому, если параметру присвоено значение 0...

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

Такой вариант не делает недействительным SolarisСоответствие POSIX. То, что это вообще вариант, квалифицирует его каксоответствующий:

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

Следующие символические константы должны быть определены со значением, отличным от -1. Если константа определена со значением ноль, приложения должны использовать функции sysconf(), pathconf(), или fpathconf()или getconfутилиту, чтобы определить, какие функции присутствуют в системе в данный момент или для конкретного рассматриваемого пути.

_POSIX_CHOWN_RESTRICTED

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

Системная chown()функция — это документированный системный вызов, выполняемый обеими сторонамиchownиchgrpутилиты оболочки - этоуказано, что не удалосьпо многим причинам. Среди них:

EACCES Разрешение на поиск отклонено для компонента префикса пути.

ELOOP В символических ссылках, обнаруженных при разрешении аргумента пути, существует цикл.

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

Однако поведение предоставления прав на изменение разрешений пользователям, не являющимся root, никогда не было уникальным для Solaris.превосходно- хотя и несколько устарело - освещение прав доступа к файлам Unix вэтот пост на форумев котором автор утверждает:

Первоначально Unix позволял владельцу файла отдавать файл. Владелец файла мог сменить владельца на кого-то другого. Не было возможности для пользователя, не являющегося root, отменить эту операцию... BSD[позже]удалено chownиз не-root пользователей...[отчасти потому, что]...он реализовал дисковые квоты, которые могли ограничивать объем дискового пространства, доступного пользователю в файловой системе... Непослушные пользователи могли раздавать большие файлы, чтобы обойти квоты.

Сегодня нелегко сказать, может ли не-root-пользователь получить chownфайл. Многие версии Unix позволяютобаповедение...

Еще один хороший - и более новый -сообщение в списке рассылкицитирует это и продолжает:

По умолчанию в большинстве ОС это chownограничение только для root. И существует консенсус, что это должно оставаться так из соображений безопасности. Если не-root пользователь меняет владельца файла и любой бит выполнения включен, биты SUIDи SGIDдолжны быть очищены. Это может произойти или не произойти с root.

Я думаю, последний абзац хорошо это иллюстрирует.

В этой статье также упоминается CAP_CHOWNуправление этой функцией в Linux.(это должно влиять только на POSIX_CHOWN_RESTRICTEDповедение). Также есть CAP_FOWNERспособность, которая немного отличается по поведению.

И в качествеВы указываете в 2003 году:

Обратите внимание, что по крайней мере в HPUX вы можете изменить владельца своих файлов.( rootнапример)даже если вы не являетесь привилегированным пользователем...

...который зависел от параметра конфигурации setprivgroup.

В любом случае, когда пользователь, не являющийся пользователем root, может манипулировать правами доступа к файлам, это возможно, как указано вобоснованиецитируется в вашем вопросе, что пользователь может chownфайл, которым владеет этот пользователь, так что он принадлежит другому пользователю. Если группа владения файлом и chownгруппы пользователя ing не совпадают, то пользователь больше не сможет изменять этот файл.

В этом сценарииchown затем chgrpпотерпит неудачу, так как у пользователя больше не будет прав на изменение прав доступа к этому файлу, тогда как chown user:group- до тех пор, покагруппапринадлежит пользователю - будет успешным.

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

Также имеется обширная документация по различным возможным эффектам прав доступа к файлам, обходу дерева и символическим ссылкам, которые могут привести к аналогичному сбою в отношении -Rэккурсивных chownприложений:

ОтPOSIX-XRAT-тестзаголовки разделовТретийиЧетвертые домены:

Обычно пользователи, указывающие опцию обхода иерархии файлов, хотят работать с одной физической иерархией, и поэтому символические ссылки, которые могут ссылаться на файлы за пределами иерархии, игнорируются. Например, chown owner file — это другая операция, чем та же команда с указанной опцией -R. В этом примере поведение команды chown owner fileописано здесь, в то время как поведение командыchown -RФайл владельца описан в третьем и четвертом доменах.

...Существует проблема безопасности при использовании логического обхода по умолчанию. Исторически сложилось так, что командаchown -Rфайл пользователя был безопасен для суперпользователя, потому чтоsetuidисетгидбиты терялись при смене владельца файла. Если бы обход был логическим, смена владельца больше не была бы безопасной, поскольку пользователь мог вставить символическую ссылку, указывающую на любой файл в дереве. Опять же, это потребовало бы добавления опции к командам, выполняющим обход иерархии, чтобы не выполнять косвенные действия через символические ссылки, а исторические сценарии, выполняющие рекурсивные обходы, мгновенно стали бы проблемами безопасности. Хотя это в основном проблема для системных администраторов, предпочтительнее не иметь разных значений по умолчанию для разных классов пользователей.

...

В 4.3 BSD chgrpпри обходе дерева менялась группа символической ссылки, а не цель. Символические ссылки в 4.4 BSD не имели владельца, группы, режима или других стандартных атрибутов файлов системы UNIX.

И из POSIXchgrpсобственно на странице есть то, что указывает на возможное неполное -Rэккурсивное действие или, по крайней мере, на то, чтоиспользовалбыть:

Версии System V и BSD используют разные коды статуса выхода. Некоторые реализации использовали статус выхода как счетчик количества произошедших ошибок; эта практика неработоспособна, поскольку может выйти за пределы диапазона допустимых значений статуса выхода. Разработчики стандарта решили замаскировать их, указав только 0 и >0 в качестве значений выхода.

Answer

TheПодсистема Microsoft Interix Unix (сейчас на пенсии)для ядра NT он обрабатывал разрешения пользователей и групп немного иначе, чем некоторые другие:

Информация о пользователях и группах хранится вБаза данных доступа к безопасности. И пользователи, и группы хранятся в одной и той же базе данных, но имена групп и пользователей должны быть уникальными; ни одна группа не может иметь имя пользователя и наоборот.(Эта база данных заменяет файлы /etc/passwdи /etc/groupsв UNIX.)Пользователи и группы создаются с использованием соответствующей методологии Windows.(Диспетчер пользователей, Пользователи и компьютеры Active Directory или Локальные пользователи и группы)или с помощью команды Win32 net user.(Примеры сценариев оболочки для создания и удаления пользователей включены в каталог /usr/examples/admin.)Пользователи могут принадлежать ко многим группам.

Вотнекоторыйболее конкретные выдержки из руководства:

В Windows владеть объектом может как пользователь, так и группа. Это отличается от UNIX, где объектом владеет только пользователь.

Windows идентифицирует всех пользователей и группы внутренне, используя идентификатор безопасности.(СИД). Алгоритм хеширования генерирует уникальные значения SID; никакие два пользователя или группы не будут иметь одинаковый SID.

Пользователи и группы, имеющие разрешение на доступ к объекту, идентифицируются по их SID. Все объекты, которые могут быть защищены Windows, имеют список дискреционного управления доступом (DACL), который состоит из отдельных записей, называемых записями управления доступом (ACE). ACE включает в себя два важных фрагмента информации: SID пользователя или группы и описание того, какой уровень доступа имеет отдельный пользователь или группа к объекту.

ЧГРП

...Измените идентификатор группы для файла... пользователь, вызывающий chgrp(1), должен принадлежать к указанной группе и быть владельцем файла или иметь соответствующие привилегии.

ЧАУН

...Операнды владельца и группы являются необязательными, однако один из них должен быть указан. Если указан операнд группы, ему должно предшествовать двоеточие (:).

Владелец может быть указан как числовым идентификатором пользователя, так и именем пользователя. Если имя пользователя также является числовым идентификатором пользователя, операнд используется как имя пользователя. Группа может быть как числовым идентификатором группы, так и именем группы. Если имя группы также является числовым идентификатором группы, операнд используется как имя группы.

По соображениям безопасности изменить права собственности на файл может только процесс с соответствующими привилегиями.

Как я понял, это означает, что если ваша учетная запись пользователя принадлежит к группе Windows с достаточными привилегиями для изменения разрешений файла, принадлежащего этой группе, то можно эффективно управлять chgrpэтим файлом вне контроля вашей учетной записи пользователя. Это означает меньший контроль, чем вы могли бы иметь с chownявными user:groupпараметрами. В этом контексте без возможности объявленияuser: и :groupвы никогда не смогли бы достичь тех же результатов, что и в противном случае.

Вот ссылкаподробному рассмотрению того, как Interix взаимодействует с ACL Windows, с акцентом на то, как эти знания могут быть применены к файловым системам Samba в других вариантах Unix.

Вот ссылкав настоящее времяустаревшийДокумент Solaris, описывающий настраиваемый параметр rstchown, который...

chown(2)Указывает , применяется ли семантика POSIX для системного вызова...

По-видимому, если параметру присвоено значение 0...

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

Такой вариант не делает недействительным SolarisСоответствие POSIX. То, что это вообще вариант, квалифицирует его каксоответствующий:

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

Следующие символические константы должны быть определены со значением, отличным от -1. Если константа определена со значением ноль, приложения должны использовать функции sysconf(), pathconf(), или fpathconf()или getconfутилиту, чтобы определить, какие функции присутствуют в системе в данный момент или для конкретного рассматриваемого пути.

_POSIX_CHOWN_RESTRICTED

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

Системная chown()функция — это документированный системный вызов, выполняемый обеими сторонамиchownиchgrpутилиты оболочки - этоуказано, что не удалосьпо многим причинам. Среди них:

EACCES Разрешение на поиск отклонено для компонента префикса пути.

ELOOP В символических ссылках, обнаруженных при разрешении аргумента пути, существует цикл.

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

Однако поведение предоставления прав на изменение разрешений пользователям, не являющимся root, никогда не было уникальным для Solaris.превосходно- хотя и несколько устарело - освещение прав доступа к файлам Unix вэтот пост на форумев котором автор утверждает:

Первоначально Unix позволял владельцу файла отдавать файл. Владелец файла мог сменить владельца на кого-то другого. Не было возможности для пользователя, не являющегося root, отменить эту операцию... BSD[позже]удалено chownиз не-root пользователей...[отчасти потому, что]...он реализовал дисковые квоты, которые могли ограничивать объем дискового пространства, доступного пользователю в файловой системе... Непослушные пользователи могли раздавать большие файлы, чтобы обойти квоты.

Сегодня нелегко сказать, может ли не-root-пользователь получить chownфайл. Многие версии Unix позволяютобаповедение...

Еще один хороший - и более новый -сообщение в списке рассылкицитирует это и продолжает:

По умолчанию в большинстве ОС это chownограничение только для root. И существует консенсус, что это должно оставаться так из соображений безопасности. Если не-root пользователь меняет владельца файла и любой бит выполнения включен, биты SUIDи SGIDдолжны быть очищены. Это может произойти или не произойти с root.

Я думаю, последний абзац хорошо это иллюстрирует.

В этой статье также упоминается CAP_CHOWNуправление этой функцией в Linux.(это должно влиять только на POSIX_CHOWN_RESTRICTEDповедение). Также есть CAP_FOWNERспособность, которая немного отличается по поведению.

И в качествеВы указываете в 2003 году:

Обратите внимание, что по крайней мере в HPUX вы можете изменить владельца своих файлов.( rootнапример)даже если вы не являетесь привилегированным пользователем...

...который зависел от параметра конфигурации setprivgroup.

В любом случае, когда пользователь, не являющийся пользователем root, может манипулировать правами доступа к файлам, это возможно, как указано вобоснованиецитируется в вашем вопросе, что пользователь может chownфайл, которым владеет этот пользователь, так что он принадлежит другому пользователю. Если группа владения файлом и chownгруппы пользователя ing не совпадают, то пользователь больше не сможет изменять этот файл.

В этом сценарииchown затем chgrpпотерпит неудачу, так как у пользователя больше не будет прав на изменение прав доступа к этому файлу, тогда как chown user:group- до тех пор, покагруппапринадлежит пользователю - будет успешным.

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

Также имеется обширная документация по различным возможным эффектам прав доступа к файлам, обходу дерева и символическим ссылкам, которые могут привести к аналогичному сбою в отношении -Rэккурсивных chownприложений:

ОтPOSIX-XRAT-тестзаголовки разделовТретийиЧетвертые домены:

Обычно пользователи, указывающие опцию обхода иерархии файлов, хотят работать с одной физической иерархией, и поэтому символические ссылки, которые могут ссылаться на файлы за пределами иерархии, игнорируются. Например, chown owner file — это другая операция, чем та же команда с указанной опцией -R. В этом примере поведение команды chown owner fileописано здесь, в то время как поведение командыchown -RФайл владельца описан в третьем и четвертом доменах.

...Существует проблема безопасности при использовании логического обхода по умолчанию. Исторически сложилось так, что командаchown -Rфайл пользователя был безопасен для суперпользователя, потому чтоsetuidисетгидбиты терялись при смене владельца файла. Если бы обход был логическим, смена владельца больше не была бы безопасной, поскольку пользователь мог вставить символическую ссылку, указывающую на любой файл в дереве. Опять же, это потребовало бы добавления опции к командам, выполняющим обход иерархии, чтобы не выполнять косвенные действия через символические ссылки, а исторические сценарии, выполняющие рекурсивные обходы, мгновенно стали бы проблемами безопасности. Хотя это в основном проблема для системных администраторов, предпочтительнее не иметь разных значений по умолчанию для разных классов пользователей.

...

В 4.3 BSD chgrpпри обходе дерева менялась группа символической ссылки, а не цель. Символические ссылки в 4.4 BSD не имели владельца, группы, режима или других стандартных атрибутов файлов системы UNIX.

И из POSIXchgrpсобственно на странице есть то, что указывает на возможное неполное -Rэккурсивное действие или, по крайней мере, на то, чтоиспользовалбыть:

Версии System V и BSD используют разные коды статуса выхода. Некоторые реализации использовали статус выхода как счетчик количества произошедших ошибок; эта практика неработоспособна, поскольку может выйти за пределы диапазона допустимых значений статуса выхода. Разработчики стандарта решили замаскировать их, указав только 0 и >0 в качестве значений выхода.

Question 2

Предположение 1: правила определения chownуспешности проверки целевого пользователя и групповой части независимо, т.е. они имеют вид user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

Предположение 2: chown(file, -1, -1)успешно.

Предположение 3: правила определения chownуспешности не зависят от того, к какой группе в данный момент принадлежит файл.

Следствие: если chown(file, uid, gid)бы это удалось, то и chown(file, -1, gid) && chown(file, uid, -1).

Я не знаю ни одного варианта Unix, который нарушал бы какие-либо из этих предположений. Они кажутся вполне безопасными.

Это предложение выглядит так, как будто кто-то из комитета сказал, когда устал после многочасовых дебатов о том, сколько опций может поместиться в заголовок вызова ps, — или как будто секретарь неправильно расшифровал — и никто не заметил во время проверки. В конце концов, есть и другие веские причины разрешить автоматическую смену пользователя и группы, включая причину производительности, также указанную в обосновании POSIX, а также атомарность (ах, если бы только был один вызов для смены владельца и разрешений).

Случай, когда предположение 3 может быть неверным, — это система, в которой процесс может получить возможность менять владельцев файлов, но только если у него есть разрешение на запись в файл. Хотя это и довольно реалистично, я не знаю ни одной системы, где это так. Затем chgrpв группу из процесса, который не запущен ни как root, ни как пользователь, владеющий файлом, может сделать файл недоступным для последующего chown.

Для рекурсивного вызова существуют пограничные случаи, когда целый проход, chgrpза которым следует целый проход, chownможет завершиться неудачей, когда один проход будет успешным. Это не очень убедительный аргумент, поскольку он включает каталоги, на обход которых у владельца нет разрешения, и приложению, которое хотело бы защититься от всех таких случаев, в любом случае пришлось бы возиться с разрешениями. Тем не менее, технически это соответствует условию этого обоснования. Предположим, что запущенный процесс имеет эффективного пользователя alice, эффективную группу staffи возможность произвольно менять владельцев файлов (а не просто отдавать их; несколько вариантов unix имеют такую возможность, хотя она редко предоставляется некорневым процессам).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied

Answer

Предположение 1: правила определения chownуспешности проверки целевого пользователя и групповой части независимо, т.е. они имеют вид user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

Предположение 2: chown(file, -1, -1)успешно.

Предположение 3: правила определения chownуспешности не зависят от того, к какой группе в данный момент принадлежит файл.

Следствие: если chown(file, uid, gid)бы это удалось, то и chown(file, -1, gid) && chown(file, uid, -1).

Я не знаю ни одного варианта Unix, который нарушал бы какие-либо из этих предположений. Они кажутся вполне безопасными.

Это предложение выглядит так, как будто кто-то из комитета сказал, когда устал после многочасовых дебатов о том, сколько опций может поместиться в заголовок вызова ps, — или как будто секретарь неправильно расшифровал — и никто не заметил во время проверки. В конце концов, есть и другие веские причины разрешить автоматическую смену пользователя и группы, включая причину производительности, также указанную в обосновании POSIX, а также атомарность (ах, если бы только был один вызов для смены владельца и разрешений).

Случай, когда предположение 3 может быть неверным, — это система, в которой процесс может получить возможность менять владельцев файлов, но только если у него есть разрешение на запись в файл. Хотя это и довольно реалистично, я не знаю ни одной системы, где это так. Затем chgrpв группу из процесса, который не запущен ни как root, ни как пользователь, владеющий файлом, может сделать файл недоступным для последующего chown.

Для рекурсивного вызова существуют пограничные случаи, когда целый проход, chgrpза которым следует целый проход, chownможет завершиться неудачей, когда один проход будет успешным. Это не очень убедительный аргумент, поскольку он включает каталоги, на обход которых у владельца нет разрешения, и приложению, которое хотело бы защититься от всех таких случаев, в любом случае пришлось бы возиться с разрешениями. Тем не менее, технически это соответствует условию этого обоснования. Предположим, что запущенный процесс имеет эффективного пользователя alice, эффективную группу staffи возможность произвольно менять владельцев файлов (а не просто отдавать их; несколько вариантов unix имеют такую возможность, хотя она редко предоставляется некорневым процессам).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied

объяснение по chown(1) POSIX spec

решение1

решение2

Связанный контент