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

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

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

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

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

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

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

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

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

2 Solutions collect form web for “пояснение о chown (1) Спецификация POSIX”

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

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

Вот еще несколько конкретных отрывков:

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

Windows идентифицирует всех пользователей и группы внутри страны с помощью идентификатора безопасности (SID) . Алгоритм хеширования генерирует уникальные значения 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 . Цикл существует в символических ссылках, встречающихся при разрешении аргумента path.

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

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

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

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

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

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

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

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

И как вы отметили в 2003 году :

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

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

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

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

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

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

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

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

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

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

И с самой страницы PSSIX chgrp есть это, что указывает на возможное незавершенное -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 
  • NFS экспортирует all_squash, anonuid, anongid, сопоставляя все клиенты клиентов с владельцем на сервере (работающем), все еще нуждающимся в возможностях для чтения на сервере?
  • проблема безопасности вокруг добавления пользователя cron в группу веб-приложений
  • Sed с редактированием inplace изменяет групповое владение файлом
  • Как изменить владельца файла в AIX?
  • Mount cifs Сетевой диск: разрешения на запись и chown
  • Как вернуть команду chown?
  • Не удается загрузить файл в контейнере lxc
  • изменить владельца файла и его родительские каталоги
  • Есть ли способ использовать chown / chgrp без изменения последней измененной даты?
  • Изменить владельца для файла резервной копии, созданного backupninja
  • Как скрыть чужие каталоги от пользователя?
  • Linux и Unix - лучшая ОС в мире.