объяснение о chown (1) спецификации POSIX

Спецификация POSIX для chownутилиты упоминает в разделе объяснения о chown user:groupсинтаксисе (ранее chown user.group) (выделено мое):

Метод BSD 4.3 для указания как владельца, так и группы был включен в этот том POSIX.1-2008, потому что:

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

Я думал, что user:groupсинтаксис был удобной вещью. Теперь вышесказанное подразумевает, что есть вещи, которые вы можете сделать с chown user:groupкоторыми вы не можетеchgrp group; chown user

Теперь этот текст не имеет смысла для меня. В 4.3BSD только root мог изменить владельца файла, поэтому в любом случае нет никаких ограничений в том, что он может делать.

SysV и несколько других систем позволяют (или используют для разрешения) владельцу файла изменять пользователя и группу файла на что угодно, но даже в этих системах этот текст выше не имеет смысла для меня. Хорошо, если кто-то это делает chown someone-else the-file, он не может сделать это chgrp something-else the-fileпозже, потому что он больше не является владельцем файла, но ничто не мешает ему / ей делать chgrpпервое (оставаясь владельцем файла) и chownпосле, и это не то, что Текст выше точно говорит.

Я не понимаю, какое отношение к этой проблеме имеет желаемый владелец и не являющийся членом текущей группы .

Итак, при каких условиях может произойти сбой функции chown (), если одновременно не будут изменены и владелец, и группа , и в какой системе?

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

Информация о пользователях и группах хранится в базе данных Security Access . И пользователи, и группы хранятся в одной базе данных, но имена групп и пользователей должны быть уникальными; ни одна группа не может иметь имя пользователя и наоборот. (Эта база данных заменяет /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

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

CHOWN

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

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

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

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

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

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

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

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

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

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

Хотя все реализации, соответствующие 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 ... [частично потому что] ... он реализовал дисковые квоты, которые могли ограничить объем дискового пространства пользователь может иметь в файловой системе ... Непослушные пользователи могут отдавать большие файлы, чтобы пройти мимо квот.

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

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

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

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

Эта статья также ссылается CAP_CHOWNна управление этим средством в Linux (это должно влиять только на POSIX_CHOWN_RESTRICTEDповедение) . Существует также CAP_FOWNERвозможность, которая немного отличается по поведению.

И как вы указали в 2003 году :

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

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

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

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

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

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

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

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

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

...

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

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

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

Предположение 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