Подробные данные файловой системы
Это приложение включает информацию о файловых системах, поддерживаемых OS X и iOS.
Поддерживаемые файловые системы
OS X поддерживает множество файловых систем и форматов объема, включая перечисленных в Таблице b-1. Несмотря на то, что основной формат объема является HFS Плюс, OS X может также загрузиться от диска, отформатированного с файловой системой UFS. Будущие версии OS X могут быть загрузочными с другими форматами объема также.
Много файловых систем требуют, чтобы определенные символы разделителя обозначили пути. Лучше использовать NSURL способы строительства файла для построения строк вместо того, чтобы делать так вручную.
Средство поиска
Поскольку Средство поиска является основным доступом пользователя к файловой системе в OS X, это помогает понять немного о как подарки Средства поиска и работы с файлами.
Правила сортировки имени файла
Порядок сортировки Средства поиска для имен файлов и имен каталогов основывается на Алгоритме сопоставления Unicode (Технический стандарт UTS № 10) определенный Консорциумом Unicode. Тот стандарт обеспечивает полное и однозначное упорядочивание вида для всех символов Unicode и доступен на Консорциальном веб-сайте Unicode (http://www .unicode.org). Средство поиска изменяет поведение сортировки значения по умолчанию этого алгоритма немного путем использования в своих интересах некоторых санкционированных альтернатив в частности:
Пунктуация и символы являются значительными для сортировки.
Подстроки цифр сортируются согласно их числовому значению, в противоположность сортировке фактических символов в числе.
Случай не рассматривают во время сортировки.
Правила представления для файлов и каталоги
Средство поиска использует несколько данных, чтобы определить, как представить файлы и каталоги. Пакет файла укусил, введите код, код создателя и расширение файла, вся справка определяет значок. Пользовательские настройки также играют роль. Следующие шаги объясняют, что процесс раньше выбирал значки для файлов и каталога:
Для файлов:
Средство поиска просит, чтобы Launch Services обеспечила надлежащий значок. (Значки файла номинально предоставлены приложением, определяющим надлежащий тип файла. Системные приложения также обеспечивают значки по умолчанию для многих известных типов файлов.)
Если никакой значок не доступен, средство поиска выводит на экран универсальный значок файла.
Для несвязанных каталогов:
Для определенных системных каталогов Средство поиска выводит на экран пользовательский значок. Эти пользовательские значки обычно являются универсальным значком папки, наложенным с изображением, указывающим цель каталога.
Для всех других каталогов система выводит на экран универсальный значок папки.
Для связанных каталогов:
Система представляет каталог как файл и не позволяет пользователю перейти далее вниз в каталог по умолчанию. (Пользователи могут все еще просмотреть содержание каталога пакета Щелчком управления каталог и Show Package Contents выбора из появляющегося контекстного меню.)
Если связанный каталог имеет расширение
.appв его имени файла Средство поиска применяет значок, связанный с комплектом приложений. Если не предоставлен никакой значок.Для связанного каталога Средство поиска ищет код типа, код создателя и расширение файла в базе данных Launch Services и использует ту информацию для определения местоположения надлежащего пользовательского значка.
Если никакой пользовательский значок не доступен ни для одного файл или каталог, Средство поиска выводит на экран значок по умолчанию, подходящий для данного типа изделия.
Значок по умолчанию может отличаться на основе того, является ли элемент документом, несвязанным каталогом, приложением, плагином или универсальным пакетом, среди других.
Типы файлов и коды создателя
Тип файла и коды создателя являются более старым способом идентифицировать тип файла и приложения, создавшего его. Код типа файла (32-разрядное значение, обычно указываемое как последовательность четырех символов), идентифицирует тип содержания, содержавшегося в файле. Код создателя (столь же идентифицированное использование последовательности четырех символов) идентифицирует приложение, создавшее файл и действия как основной редактор для того определенного файла. Несмотря на то, что эти коды обычно осуждаются, можно видеть их в устаревших файлах и приложениях и в некоторых местах в системе.
Защита файловой системы OS X
OS X обеспечивает политики защиты файловой системы, что предельный доступ к файлам и каталогам (включая специальные файлы и каталоги, такие как точки монтирования для объемов, блока и символьных файлов специального устройства, представляющих устройства, символьные ссылки, именованные каналы, сокеты домена UNIX, и т.д.). Это приложение объясняет эти политики и как они влияют на приложения.
Схемы безопасности
OS X обеспечивает три схемы защиты файловой системы: UNIX (BSD) полномочия, списки управления доступом POSIX (ACLs) и права песочницы. Кроме того, уровень BSD обеспечивает несколько флагов на файл то переопределение полномочия UNIX. Эти схемы описаны в следующих разделах.
Кроме того, OS X позволяет администраторским пользователям отключать владение и проверку полномочий съемные объемы на основе на объем путем выбора Get Info на объеме в Средстве поиска, затем проверки флажка «Ignore ownership on this volume».
Эти модели полномочий совмещаются следующим образом:
Если песочница приложения запрещает запрошенный доступ, запрос отклонен. Посмотрите Права Песочницы для подробных данных.
Если проверка владения была отключена для рассматриваемого объема системным администратором (с флажком в его окне Finder Get Info), запрос предоставляют.
Если элемент списка управления доступом существует на файле, он оценивается и используется для определения прав доступа. Посмотрите POSIX ACLs для подробных данных.
Если флаг файла запрещает работу, работа отклонена. Посмотрите Флаги Файла BSD для подробных данных.
Иначе, если идентификатор пользователя соответствует владельцу файла, «пользовательские» полномочия (также названный полномочиями «владельца») используются. См. Полномочия UNIX для подробных данных.
. Иначе, если группа, которую ID соответствует группе для файла, полномочия «группы» используется, см. Полномочия UNIX для подробных данных.
Иначе, «другие» полномочия используются. См. Полномочия UNIX для подробных данных.
Права песочницы
OS X поддерживает использование песочницы для ограничения возможности приложения получить доступ к файлам. Эти пределы переопределяют любые полномочия, которые могло бы иначе иметь приложение. Пределы песочницы являются отнимающими, не аддитивными. Поэтому полномочия файловой системы представляют максимальный доступ, который могло бы быть позволено приложение, если его песочница также разрешает тот доступ.
POSIX ACLs
Начиная с OS X v10.4, Мах и политики полномочий BSD дополняются поддержкой в ядре для ACLs (списки управления доступом), которые являются структурами данных, обеспечивающими намного более подробное управление полномочиями, чем делает BSD. Например, ACLs позволяют системному администратору указывать, что определенный пользователь может удалить файл, но не может записать в него. ACLs также предоставляют совместимости Active Directory и сети SMB/CIFS, используемые операционной системой Windows. Для получения дополнительной информации о поддержке ACL в OS X для различных сетевых файловых систем посмотрите Сетевые файловые системы.
ACL состоит из упорядоченного списка ACEs (элементы списка управления доступом), каждый из которых связывает пользователя или группу с рядом полномочий и указывает, позволено ли каждое разрешение или отклонено. ACEs также включает атрибуты, связанные с наследованием (см. Наследование Полномочий).
Политика управления доступом к файловой системе
Можно использовать файловую систему ACLs для реализации более подробной и сложной политики контроля доступа, чем возможен использующий только полномочия BSD. Они делают так при помощи еще многих битов полномочий, чем эти три, используемые BSD и путем реализации, и разрешают и отклоняют ассоциации для каждого разрешения для каждого пользователя или группы. Таблица b-2 показывает биты полномочий, используемые ACLs. Сравните их с битами полномочий BSD, показанными в Таблице b-3.
Бит | Файл | Каталог |
|---|---|---|
читать | Открытый файл для чтения | Содержание каталога списка |
записать | Открытый файл для записи | Добавьте запись файла в каталог |
выполниться | Выполните файл | Переройте каталог (к файлам или каталогам доступа в нем) |
удалить | Удалите файл | Каталог Delete |
добавить | Добавьте к файлу | Добавьте подкаталог к каталогу |
удалите дочерний элемент | — | Удалите файл или запись подкаталога из каталога |
считайте атрибуты | Считайте основные атрибуты | Считайте основные атрибуты |
запишите атрибуты | Запишите основные атрибуты | Запишите основные атрибуты |
читайте расширенный | Считайте расширенные (названные) атрибуты | Считайте расширенные (названные) атрибуты |
запишите расширенный | Запишите расширенные (названные) атрибуты | Запишите расширенные (названные) атрибуты |
считайте полномочия | Считайте полномочия файла (ACL) | Считайте полномочия каталога (ACL) |
запишите полномочия | Запишите полномочия файла (ACL) | Запишите полномочия каталога (ACL) |
возьмите владение | Возьмите владение | Возьмите владение |
Заметьте, что правом изменить полномочия самостоятельно управляет разрешение.
ACLs и идентификаторы пользователей
Одна из главных причин для реализации ACLs в OS X состоит в том, чтобы поддерживать сетевые файловые системы, такие как SMB/CIFS (см. SMB/CIFS). Чтобы быть в состоянии идентифицировать пользователей и группы всюду по сети, каждый файл или каталог должен иметь универсально уникальные идентификаторы (UUIDs) в дополнение к локально уникальному UID и GID, используемому BSD. Каждый файл или каталог, связавший ACLs, поэтому, имеет четыре связанных идентификационных данные, два для поддержки BSD и два для поддержки ACLs:
Идентификатор пользователя (UID)
Группа ID (GID)
Владелец UUID
Группа UUID
В отличие от BSD, указывающего три полномочий для каждого файла (один для владельца файла, один для элементов группы файла, и один для всех остальных), ACL может указать различные полномочия для каждого ACE. Другой контраст между ACLs и BSD - то, что, тогда как в BSD владелец файла должен быть частным лицом в разрешении ACL, интригуют, владелец файла может быть или пользователем или группой. Если файл принадлежит группе, ее GID (используемый BSD) и группе, UUID являются всегда когерентными (т.е. всегда существует простое, 1:1 отображающийся между ними). Однако, потому что BSD не поддерживает понятие группы как владелец файла, в этом случае система присваивает специальный UID, идентифицирующий файл, как принадлежится “не пользователь” и владелец, UUID представляет группу. Если файл принадлежит единственному частному лицу, его UID и владельцу, UUID являются когерентными.
У владельца файла с помощью ACL есть определенные безотзывные полномочия (чтение и полномочия записи) независимо от содержания ACL. Если файл принадлежит частному лицу, группа UUID связывает группу с объектом файловой системы и влияет на наследование определенного ACEs (см. Наследование Полномочий), но не присуждает специальных полномочий группе.
Оценка списков управления доступом
Каждый ACE в ACL или позволяет или отклонение некоторого набора полномочий. Очень важно понять, что отклонять ACE не является тем же как отсутствием позволить ACE. Скорее система оценивает ACEs в последовательности, пока или все требуемые полномочия не позволяются или никакое требуемое разрешение, отклонен. Запрос на авторизацию включает учетные данные (который идентифицирует объект запроса), и полномочия, требуемые для работы. OS X v10.4 и позже оценивает полномочия с помощью следующего алгоритма (также, посмотрите Наследование Полномочий для обсуждения наследованных полномочий):
Если требуемые полномочия изменили бы объект, и файловая система только для чтения, или объект отмечен как неизменный, работа отклонена.
Если объект, обращающийся с просьбой, является пользователем root, работа позволяется.
Если объект, обращающийся с просьбой, является владельцем объекта, просителю дают Полномочия Чтения и доступ Полномочий Записи. Если это достаточно для удовлетворения запроса, работа позволяется.
Если объект имеет ACL, ACEs в ACL сканируется в порядке. (Те с отклоняют ассоциации, обычно помещаются, прежде чем те с разрешают ассоциации.) Каждый ACE оценен согласно следующим критериям, пока или требуемое разрешение не было отклонено, все требуемые полномочия были позволены, или конец ACL достигнут:
ACE проверяется на применимость. ACE не считают применимым, если это не обращается ни к одним из требуемых полномочий. Кроме того, объект запроса должен совпасть с объектом, названным в ACE, или проситель должен быть участником группы, названной в ACE. (Группы могут быть вложены, и внешняя служба каталогов может использоваться для разрешения состава группы.) Неприменимый ACEs проигнорирован.
Если ACE отклоняет какие-либо из требуемых полномочий, то запрос отклонен. (Обратите внимание на то, что Полномочия Чтения и Полномочия Записи предоставляет владельцу объекта, независимо от или позволяет или отклоняет ACEs.)
Если ACE позволяет какие-либо из требуемых полномочий, система добавляет это разрешение к списку данных разрешений. Если данные разрешения включают все требуемые полномочия, запрос позволяется и остановки процесса. Если список не завершен, система продолжает проверять следующий ACE.
Если конец ACL достигнут, не находя все требуемые полномочия, и если объект также имеет полномочия BSD, то система проверяет неудовлетворенные полномочия по полномочиям BSD. Если они достаточны для давания всех требуемых разрешений, запрос позволяется. Если разрешение, которое требуют, не имеет никакого эквивалентного BSD (те, которые “берут владение”), то это считают все еще выдающимся, и запрос отклонен.
Если объект файловой системы не имеет никакого ACL, то полномочия оценены согласно политике безопасности BSD, как описано в Полномочиях UNIX и Флагах Файла BSD.
Учетные данные объекта запроса эквивалентны эффективному UID (т.е. EUID) программы, пытающейся открыть или выполнить файл. EUID обычно является тем же как UID пользователя, или обработайте, который выполняет процесс., но это может отличаться по особым обстоятельствам (включающий бит setuid), как описано во Владельце или Корневой Политике безопасности.
Наследование полномочий
Полномочия BSD присваиваются только на основе на файл, так, чтобы полномочия, присвоенные каталогу, не влияли на полномочия нового файла или подкаталога, создаваемого в том каталоге. Несмотря на то, что можно применить полномочия каталога к вложенным элементам, делание так является разовой работой. Любые недавно создаваемые файлы или подкаталоги не затронуты — они создаются с полномочиями по умолчанию.
С ACLs, в отличие от этого, недавно создал файлы, и подкаталоги могут наследовать полномочия из своего каталога включения. Каждый ACE на каталоге может содержать любую комбинацию следующих флагов наследования:
Наследованный (этот ACE был наследован),
Файл Наследовался (этот ACE должен быть наследован файлами, создаваемыми в этом каталоге),
Каталог Наследовался (этот ACE должен быть наследован каталогами, создаваемыми в этом каталоге),
Наследуйтесь Только (этот ACE не должен быть проверен во время авторизации),
Нет Распространите, Наследовались (этот ACE должен быть наследован только прямыми дочерними элементами; т.е. ACE должен проиграть, любой Каталог Наследовались, или Файл Наследовали бит, когда наследовано),
Когда это создает новый файл, ядро проходит через весь список управления доступом родительского каталога и копирует в ACL файла любой ACEs, отмеченный для наследования файла. Точно так же, когда это создает новый подкаталог, ядро копирует в ACL подкаталога любой ACEs, отмеченный для наследования каталога.
Если файл копируется и вставляется в каталог, ядро тиражирует содержание исходного файла в новый файл в месте назначения. Поскольку это создает новый файл, система проверяет ACL родительского каталога и добавляет, что любой наследовался, ACEs к любому ACEs был в исходном файле. Если файл перемещен в каталог, с другой стороны, исходный файл не тиражирован, и никакой ACEs не наследован. В этом случае ACEs родительского каталога добавляется к перемещенному файлу, только если администратор в частности распространяет ACEs от родительского каталога до содержавших файлов и подкаталогов. Точно так же, как только файл был создан, изменение ACL родительского каталога не влияет на ACL содержавших файлов и подкаталогов, если администратор в частности не распространяет изменение.
В BSD, применяя полномочия каталога к вложенным файлам и подкаталогам полностью заменяет полномочия вложенных объектов. С ACLs, напротив, наследовался, ACEs уже добавляется к другому ACEs на файле или каталоге.
Порядок, в котором ACEs помещается в ACL — и поэтому порядок, в котором они оценены для определения полномочий — следующие:
Явно указанный отклоняют ассоциации
Явно указанный разрешают ассоциации
Наследованные ассоциации, в том же порядке, в котором они появились в родителе
Поэтому любой явно указанный ACEs имеет приоритет по всем, наследовал ACEs. Для получения дополнительной информации о том, как ACEs оценен, видит Списки управления доступом Оценки.
Поскольку ACEs может быть наследован, администраторы могут управлять тонкозернистыми полномочиями файлов, создаваемых в каталоге путем присвоения наследуемого ACEs каталогу. Выполнение так сохраняет работу присвоения ACEs к каждому файлу индивидуально. Кроме того, потому что ACEs может примениться к группам пользователей, администраторы могут присвоить полномочия группам вместо того, чтобы иметь необходимость указать полномочия для каждого частного лица. Применение безопасности доступа к каталогам и группам, а не к файлам и частным лицам сохраняет время администратора и дает лучшую производительность файловой системы при многих обстоятельствах.
Для программистов приложения автоматическое наследование ACEs значительно упрощает работу с полномочиями файла. Вы не должны создавать ACL каждый раз, когда Вы создаете новый файл. Вы также не должны поддерживать, наследовал ACEs, сохранив файлы. Вместо этого ядро автоматически создает ACL для каждого нового файла с помощью, наследовал ACEs.
Обратите внимание на то, что присвоение и наследование полномочий BSD не затронуты ACLs. Если ACLs не поддерживаются, полномочия BSD используются. Для получения дополнительной информации о пути оценены полномочия, когда и ACLs и полномочия BSD установлены, см. Схемы Безопасности.
В Сервере OS X v10.4, администратор сервера может выполнить следующие операции:
Полномочия копии от родительского каталога до всех файлов и каталогов ниже его в иерархии. Это делает универсальную форму полномочий в дереве каталогов и должно использоваться только для полномочий BSD.
Распространите полномочия от родительского каталога до всех файлов и каталогов ниже его в иерархии. В этом случае явно указанный ACEs неизменен, и ACEs, наследованный от них, неизменен. Файлы и подкаталоги наследовали ACEs, как будто они были недавно созданы на месте в соответствии с каталогами, явно указавшими ACEs, как проиллюстрировано на рисунке b-1.
Примените наследование от родительского каталога до определенного каталога или файла.
Сделайте наследованный ACEs в каталогах явным.
Удалите весь ACEs из каталогов и файлов.
Включите или отключите ACLs на объеме.
Сервер GUI не может непосредственно управлять ACEs файлов. Нет никакого GUI в Средстве поиска, чтобы установить или изменить ACEs. ACEs Может быть считан и устанавливает и на сервере и на клиенте, использующем инструменты командной строки ls и chmod.
Флаги файла BSD
В дополнение к стандартным полномочиям файла UNIX OS X поддерживает несколько флагов файла BSD, предоставленных chflags API и связанное chflags команда. Эти флаги переопределяют полномочия UNIX.
Имя флага C Имя командной строки | Шестнадцатеричное значение | Значение |
|---|---|---|
|
| Не копируйте файл при использовании UNIX Этот флаг может быть изменен или владельцем файла или суперпользователем ( |
|
| Файл не может быть перемещен, переименован или удален (кроме Этот флаг может быть изменен или владельцем файла или суперпользователем ( |
|
| Программное обеспечение может только добавить к файлу, не изменить существующие данные. Этот флаг может быть изменен или владельцем файла или суперпользователем ( |
|
| Каталог непрозрачен относительно объединения, монтируется. Это означает, что, если каталог в базовой файловой системе существует и имеет то же имя, его содержание не видимо. Этот флаг может быть изменен или владельцем файла или суперпользователем ( |
---------- |
| Зарезервированный. |
(никакая эквивалентная команда) |
| Файл сжат на уровне файловой системы. Этот флаг может быть изменен или владельцем файла или суперпользователем ( |
---------- |
| Зарезервированный. |
|
| Подскажите, что файл должен быть скрыт в GUI. Этот флаг может быть изменен или владельцем файла или суперпользователем ( |
|
| Файл был заархивирован. Этот флаг может быть изменен только суперпользователем ( |
|
| Файл не может быть перемещен, переименован или удален (кроме Этот флаг может быть изменен только суперпользователем ( |
|
| Программное обеспечение может только добавить к файлу, не изменить существующие данные. Этот флаг может быть изменен только суперпользователем ( |
Полномочия UNIX
Каждый объект файловой системы имеет ряд полномочий UNIX, определенных тремя атрибутами:
UID, короткий для идентификатора пользователя. Обычно называемый Владельцем Файла.
GID, короткий для группы ID.
Флаги, включающие биты полномочий и другие связанные атрибуты.
Флаги для файла или каталога являются 16-разрядным значением, часто представляющимся как трехразрядное или четырехразрядное восьмеричное значение (с лучшими отброшенными четырьмя или семью битами):
Биты 12–15: Флаги, указывающие тип файла. Эти биты являются неизменными и опущены при представлении полномочий.
Биты 9–11: Специальные биты полномочий описаны в Таблице b-4. Обычно 0; если не устанавливает, может быть опущен.
Биты 6–8: биты прав Владельца. Эти биты ограничивают доступ любым процессом, эффективный идентификатор пользователя которого (EUID) равен UID файла или каталога).
Эти биты имеют наивысший приоритет.
Биты 3–5: биты прав Группы. Эти биты ограничивают доступ любым процессом с эффективной группой ID (EGID) соответствие GID файла или каталога.
Эти права не применяются ни к какому процессу, EUID которого соответствует UID файла или каталога. Эти биты имеют более низкий приоритет, чем права Владельца, но более высокий приоритет, чем Другие права.
Биты 0–2: Другие биты прав. Эти биты применяются к любому процессу, не соответствующему ни UID, ни GID файла или каталога.
Владелец, Группа и Другие наборы битов содержат три бита: читайте, запишите, выполнитесь (rwx если коротко). Эффект этих битов отличается для файлов и каталогов, как показано в Таблице b-3.
Бит | Файл | Каталог |
|---|---|---|
читать | Может открыть файл для чтения | Может перечислить содержание каталога |
записать | Может открыть файл для записи | Может изменить содержание каталога (перемещение, переименуйте или удалите включенные файлы или каталоги), |
выполниться | Может обработать файл как программу для выполнения | Может перерыть каталог (к файлам или каталогам доступа в нем) |
В дополнение к r, w, и x биты, каждый объект файловой системы также имеет три вспомогательных бита полномочий: setuid, setgid, и sticky.
Бит | Файл | Каталог |
|---|---|---|
setuid | Для двоичной исполнимой программы, когда выполняется, EUID получающегося процесса установлен в UID файла вместо EUID родительского процесса. RUID получающегося процесса все еще установлен в EUID родительского процесса, как обычно. Этот флаг не имеет никакого эффекта для интерпретируемых сценариев или неисполняемых файлов. | UID любого файла или каталога, создаваемого в каталоге, установлен в UID каталога. |
setgid | Для двоичной исполнимой программы, когда выполняется, EGID получающегося процесса установлен в GID файла вместо EGID родительского процесса. RGID получающегося процесса все еще установлен в EGID родительского процесса, как обычно. Этот флаг не имеет никакого эффекта для интерпретируемых сценариев или неисполняемых файлов. | GID любого файла или каталога, создаваемого в каталоге, установлен в GID каталога. |
липкий | Никакой эффект в OS X. Для мобильности необходимо избежать устанавливать этот бит, поскольку это действительно имеет эффект в других вариантах UNIX. | Ограничивает удаление вложенных файлов или каталогов к читающему трех пользователей:
|
Например, если владелец двоичного исполняемого файла является пользователем root, и setuid укусил, установлен, программа всегда работает с EUID 0. Поскольку такая программа работает с полномочиями пользователя root, когда выполняется кем-то другим, чем root, это может создать уязвимость системы обеспечения безопасности. Поэтому важно ограничить создание и использование setuid и setgid программ.
Пользователь может изменить полномочия только на файлах, принадлежавших тому пользователю. Поэтому только пользователь root может установить setuid, обдумал программу, принадлежавшую root.
Полномочия UNIX видимы пользователям в Терминале и в Средстве поиска. В Терминале они похожи на это:
$ ls -ld filename dirname |
drwxr-xr-x 2 username groupname 68 Jun 16 13:40 dirname |
-rw-r--r-- 1 username groupname 0 Jun 16 13:40 filename |
Формат полномочий (в левом) описан далее в Безопасности Сценария оболочки в Shell, Пишущем сценарий Учебника для начинающих.
В Средстве поиска полномочия UNIX принимают форму Владения и информации о Полномочиях в файле или Информационном диалоговом окне папки (рисунок b-3).
Специальные пользователи и группы
Этот раздел перечисляет определенных пользователей и группы в OS X, поднявшие полномочия или право получить поднятые полномочия.
Пользователь root
Пользователь root владеет многими основными системными процессами и имеет неограниченный доступ к объектам файловой системы на устройствах, присоединенных к компьютеру. Например, пользователь root может:
Считайте, запишите и выполните любой файл
Копия, переместитесь и переименуйте любой файл или папку
Владение передачи и полномочия сброса для любого файла
Существенное различие между стандартной семантикой разрешения BSD и реализацией OS X - то, что в OS X пользователь root отключен после установки системы. В большинстве случаев не необходимо для администратора работать как root (см. Admin Group). Можно также принять корневое питание при помощи sudo утилита. Несмотря на то, что sudo утилита не требует, чтобы Вы включили пользователю root, можно использовать ее только из Терминального приложения; т.е. у Вас должен быть физический доступ к машине для использования его. Посмотрите sudo страница справочника для получения дополнительной информации о ее использовании.
Пользователю root нельзя включить в пользовательских системах. Если Ваше приложение должно выполнить операции как пользователя root, необходимо использовать Authorization Services. Для получения дополнительной информации см. Руководство по программированию Authorization Services C Reference and Authorization Services в Документации Безопасности.
Принимая во внимание, что большинство полномочий пользователя применяется через сети, setuid и setgid часто игнорируются на сетевых томах, как понятие о пользователе root.
Например, при доступе к удаленным объемам по NFS, по умолчанию, пользователь root ни на ком не отображается — специальный пользователь с очень небольшим доступом. Это предотвращает пользователя root на одном компьютере от становления пользователем root на другом компьютере.
Wheel Group
Существует специальная группа в BSD, названном группой колеса. Членство в группе колеса присуждает пользователям возможность стать пользователем root при помощи su утилита на командной строке. Пользователи, которые не находятся в группе колеса, не могут стать пользователем root, даже если у них есть правильный пароль.
В OS X v 10.3 и позже, не используется группа колеса. Его функции были приняты admin группа.
Admin Group
OS X обеспечивает admin группа вместо пользователя root. Элемент администраторской группы (называемый администратором) может выполнить почти все функции, пользователь root может и может сделать их использующий Средство поиска — т.е. не обращаясь к командной строке. Единственная вещь, которую администратору препятствуют делать, непосредственно добавляет, изменение или удаление файлов в системном домене. Администратор может использовать специальные приложения, такие как Установщик или Обновление программного обеспечения с этой целью, как бы то ни было.
Пользователь, устанавливающий OS X в системе, становится автоматически первым администратором для системы. После того этот пользователь (или любой другой администратор) может использовать предпочтения Учетных записей для создания учетных записей в локальной системе для новых пользователей и может предоставить административные привилегии любому пользователю в системе.
Сетевые файловые системы
В этом разделе рассматриваются использование полномочий протоколами сетевого файлового сервера. OS X поддерживает четыре протокола сетевого файлового сервера:
AFP. Файловый протокол Apple, основной протокол совместного доступа к файлам в Mac OS 9 систем, используемых серверами AppleShare и клиентами.
NFS. Сетевая файловая система, основной протокол совместного доступа к файлам используется системами UNIX.
SMB/CIFS. Блок серверных сообщений / Общая межсетевая файловая система, протокол совместного доступа к файлам, используемый на Windows и системах UNIX
WebDAV. Веб-Распределенная Авторская разработка и Управление версиями, расширение HTTP, позволяющего совместное управление файлами в сети.
AFP
Если клиент и сервер AppleShare оба AFP 3.0 поддержки, фактические полномочия BSD транспортируются по соединению. Если файл или каталог на сервере AFP имеет ACL, ACL транспортируется по соединению, и эффективные полномочия выведены на экран Средством поиска. Однако осуществление полномочий сделано только на сервере, не на клиенте. Посмотрите POSIX ACLs для получения дополнительной информации о реализации OS X ACLs.
Если соединение использует AFP 2.x, знают о различиях в том, как работают полномочия:
BSD поддерживает полномочия на файлах, тогда как AFP 2.x не делает.
BSD проводит “лучшее соответствие” политика полномочий. Если Вы - владелец, Вы получаете полномочия владельца. Если Вы не владелец, но Вы находитесь в группе файла, Вы получаете полномочия группы. Иначе Вы получаете другие полномочия. AFP проводит кумулятивную политику полномочий: Ваши полномочия являются объединением полномочий, которые Вы получаете от владельца, группы и других полномочий. Например, если папка перезаписываема группой, но не владельцем, полномочия AFP позволяют владельцу изменить папку, но полномочия BSD не делают.
BSD интерпретирует
rwxбиты для папок как показано в Таблице b-3. Полномочия AFP определяют их, поскольку “Видят Файлы”, “Видят, что Папки”, и “Вносят Изменения”. При контакте с сервером AppleShare 2.x OS X клиент AppleShare отображается между этими моделями полномочия. Когда Вы соединяетесь с сервером OS X с помощью клиента AppleShare 2.x, подобное отображение применяется.ACLs не поддерживаются AFP 2.x.
AFP исключает процесс, имеющий EUID 0 (т.е. одно выполнение как root) от доступа к любым данным по сети.
NFS
В целом NFS не является защищенным протоколом, потому что большинство серверов NFS доверяет своим клиентам. Т.е. если клиент говорит, что эта работа файла сделана от имени пользователя Боба, сервер делает работу от имени пользователя Боба. Однако, если у Вас есть корневой доступ на клиенте, можно симулировать быть пользователем Бобом и доступом любой из файлов Боба на сервере NFS. Для поддержания некоторой безопасности большинство серверов NFS отображает пользователя root на специального пользователя, nobody, которому не принадлежат никакие файлы или каталоги. Поэтому, если Ваш EUID 0, можно, в целом, получить доступ только к тем файлам на сервере NFS, предоставляющим доступ к «другому».
SMB/CIFS
SMB является сетевым протоколом для совместного доступа к файлам, обычно используемого в сетях Windows. CIFS часто используется в качестве синонима для SMB. Samba является программным обеспечением, реализующим сервер SMB/CIFS на UNIX. Поэтому этот протокол организации общего доступа к файлам по-разному упоминается как SMB, CIFS, SMB/CIFS, Samba и совместный доступ к файлам Windows.
OS X v10.4 и более поздние реализации списки управления доступом SMB/CIFS-compatible (ACLs). Несмотря на то, что отдельные пользователи не могут установить или изменить ACLs, администраторы сервера могут сделать так. (Администраторы могут использовать командную строку сервера SMB для управления ACLs, но только если оба клиент и сервер связываются с тем же доменом Active Directory.) Однако осуществление полномочий сделано только на сервере, не на клиенте. Посмотрите POSIX ACLs для получения дополнительной информации о реализации OS X ACLs.
Для OS X v10.3 и ранее, все средства управления доступом SMB в OS X реализованы на сервере, не клиенте. Следовательно, когда пользователь OS X монтирует файловый сервер SMB, объем, каталог, или смонтированный файл, кажется, в Средстве поиска позволяет чтение, пишет, и доступ на выполнение и принадлежит пользователю. Однако, когда пользователь пытается открыть папку или файл, сервер оценивает права доступа пользователя и или предоставляет доступ или предлагает пользователю новое имя пользователя и пароль прежде, чем предоставить доступ.
Для получения дополнительной информации о полномочиях SMB/CIFS и изучить, как изменить их поведение, см. страницу справочника для SMB (man 5 smb.conf).
WebDAV
Протокол WebDAV является расширением протокола HTTP, позволяющего пользователям писать и редактировать веб-контент удаленно; т.е. по сетевому соединению. OS X файловая система WebDAV использует WebDAV и Запросы HTTP для доступа к ресурсам на поддерживающем WebDAV сервере HTTP как файлы и каталоги.
Протокол WebDAV не поддерживает пользователей и группы. Кроме того, клиент WebDAV не может определить права доступа для файлов и каталогов на сервере WebDAV прежде, чем попытаться получить доступ к ним. Поэтому файловая система WebDAV в OS X устанавливает пользователя и группу IDs к unknown для всех файлов и каталогов и значения по умолчанию полномочий к read, write, и execute для всех: пользователь, группа и другой.
Когда файловая система WebDAV отправляет запрос к поддерживающему WebDAV серверу HTTP, сервер определяет, требуется ли авторизация. Если никакая авторизация не требуется, сервер принимает запрос. Если авторизация требуется, проверки сервера на учетные данные аутентификации (такие как имя пользователя и пароль) и, если они присутствуют и корректны, сервер авторизовывает клиент и предоставляет доступ. Если авторизация требуется, и никакие учетные данные не были отправлены, или учетные данные не корректны, сервер отклоняет запрос с проблемой для аутентификации. Если пользователь не может предоставить корректные учетные данные, файловая система WebDAV отказывает в доступе.
Для получения дополнительной информации о протоколах, используемых файловой системой WebDAV, см. следующие документы:
Протокол передачи гипертекста — HTTP/1.1http://www.ietf.org/rfc/rfc2616.txt
Аутентификация HTTP: основной и доступ обзора Authenticationhttp://www.ietf.org/rfc/rfc2617.txt
Расширения HTTP для распределенной авторской разработки — WEBDAVhttp://www.ietf.org/rfc/rfc2518.txt
Защита файловой системы iOS
Несмотря на то, что базовая модель полномочий в iOS совпадает с в OS X, на практике, приложения для iOS ограничиваются их песочницей, таким образом, что приложение может обычно только получить доступ к файлам, создаваемым тем приложением. (Приложения могут получить доступ к определенным другим файлам, таким как данные адресной книги и фотографии, но только через APIs, специально предназначенный с этой целью.)
Кроме того, если защита файла включена на устройстве на iOS, приложения могут принять решение предотвратить доступ к определенным файлам к тому, когда заблокировано устройство. Вы могли бы сделать это для файлов, содержащих данные частного пользователя или уязвимую информацию.
Как с цепочкой для ключей, зашифрованные файлы в iOS также шифруются в любых резервных копиях мобильного устройства. В дополнение к включению шифрования можно также заставить файл быть исключенным из появления в резервных копиях полностью.
Для получения дополнительной информации о защите файла APIs, посмотрите информацию в Усовершенствованных Приемах Приложения в Руководстве по программированию приложения для iOS.