Разрешения файловой системы

Разрешенные действия в файловых системах

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

Широко распространены два типа разрешений: разрешения файловой системы POSIX и списки контроля доступа (ACL), которые позволяют осуществлять более конкретный контроль.

Варианты файловой системы

В исходной файловой системе File Allocation Table для каждого файла установлен атрибут «только для чтения» для всех пользователей.

NTFS , реализованная в Microsoft Windows NT и ее производных, использует списки управления доступом [1] для предоставления сложного набора разрешений.

OpenVMS использует схему разрешений, похожую на схему Unix. Существует четыре категории (система, владелец, группа и мир) и четыре типа разрешений доступа (чтение, запись, выполнение и удаление). Категории не являются взаимно непересекающимися: мир включает группу, которая в свою очередь включает владельца. Категория система независимо включает системных пользователей. [2]

HFS и его преемник HFS+ , реализованные в классических операционных системах Mac OS , не поддерживают разрешения.

macOS использует разрешения, совместимые с POSIX, и поддерживает их как в HFS+, так и в APFS . Начиная с версии 10.4 («Tiger»), он также поддерживает использование списков контроля доступа NFSv4 в дополнение к разрешениям, совместимым с POSIX. В руководстве по администрированию файловых служб Apple Mac OS X Server версии 10.4+ рекомендуется использовать только традиционные разрешения Unix, если это возможно. macOS также по-прежнему поддерживает атрибут «Protected» классической Mac OS.

Поддержка Solaris ACL зависит от используемой файловой системы; более старая файловая система UFS поддерживает POSIX.1e ACL, тогда как ZFS поддерживает только NFSv4 ACL. [3]

Linux поддерживает ext2 , ext3 , ext4 , Btrfs и другие файловые системы, многие из которых включают POSIX.1e ACL. Существует экспериментальная поддержка NFSv4 ACL для файловых систем ext3 [4] и ext4.

FreeBSD поддерживает списки контроля доступа POSIX.1e на UFS и списки контроля доступа NFSv4 на UFS и ZFS. [5] [6]

IBM z/OS реализует безопасность файлов с помощью RACF (Resource Access Control Facility) [7] [ постоянная мертвая ссылка ‍ ]

Файловая система AmigaOS, AmigaDOS поддерживает систему разрешений, относительно развитую для однопользовательской ОС. В AmigaOS 1.x файлы имели разрешения/флаги Archive, Read, Write, Execute и Delete (совместно известные как ARWED). В AmigaOS 2.x и выше были добавлены дополнительные разрешения/флаги Hold, Script и Pure.

Операционная система OpenHarmony наряду с ее клиентской экосистемой в Oniro OS и HarmonyOS с версиями HarmonyOS NEXT , а также серверная ОС openEuler на базе Linux изначально использует свою распределенную файловую систему Harmony (HMDFS), которая поддерживает менеджер токенов доступа ( управление доступом на основе ролей ) и API Core File Kit на основе возможностей с детализированным управлением разрешениями за исключением openEuler. [8] [ проверка не удалась ]

Разрешения POSIX

Разрешения в файловых системах типа Unix определены в стандарте POSIX.1-2017, [9] который использует три области действия или класса, известные как владелец , группа и другие . Когда файл создается, его разрешения ограничиваются umask процесса , который его создал.

Классы

Файлы и каталоги принадлежат пользователю. Владелец определяет класс пользователя файла . К владельцу применяются отдельные разрешения.

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

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

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

Разрешения

Unix-подобные системы реализуют три конкретных разрешения, которые применяются к каждому классу:

  • Разрешение на чтение предоставляет возможность читать файл. При установке для каталога это разрешение предоставляет возможность читать имена файлов в каталоге, но не позволяет узнать о них дополнительную информацию, такую ​​как содержимое, тип файла, размер, владелец, разрешения.
  • Разрешение на запись предоставляет возможность изменять файл. При установке для каталога это разрешение предоставляет возможность изменять записи в каталоге, включая создание файлов, удаление файлов и переименование файлов. Для этого требуется, чтобы также было установлено разрешение на выполнение ; без него разрешение на запись для каталогов бессмысленно.
  • Разрешение на выполнение предоставляет возможность выполнить файл. Это разрешение должно быть установлено для исполняемых программ, чтобы позволить операционной системе запускать их. При установке для каталога разрешение на выполнение интерпретируется как разрешение на поиск : оно предоставляет возможность доступа к содержимому файла и метаинформации, если его имя известно, но не к списку файлов внутри каталога, если также не установлено разрешение на чтение .

Эффект установки прав доступа к каталогу, а не к файлу, является «одной из наиболее часто неправильно понимаемых проблем с правами доступа к файлам» [10] .

Если разрешение не установлено, соответствующие права отклоняются. В отличие от систем на основе ACL, разрешения в Unix-подобных системах не наследуются. Файлы, созданные в каталоге, не обязательно имеют те же разрешения, что и этот каталог.

Изменение поведения разрешений с помощью setuid, setgid и sticky bits

Unix-подобные системы обычно используют три дополнительных режима. На самом деле это атрибуты, но они называются разрешениями или режимами. Эти специальные режимы предназначены для файла или каталога в целом, а не для класса, хотя в символической нотации (см. ниже) бит setuid устанавливается в триаде для пользователя, бит setgid устанавливается в триаде для группы, а бит sticky устанавливается в триаде для других.

  • Режим set user ID , setuid или SUID. При выполнении файла с setuid результирующий процесс примет эффективный идентификатор пользователя, предоставленный классу владельца. Это позволяет временно рассматривать пользователей как root (или другого пользователя).
  • Разрешение set group ID , setgid или SGID. При выполнении файла с setgid результирующий процесс примет идентификатор группы , заданный для класса группы. Когда setgid применяется к каталогу, новые файлы и каталоги, созданные в этом каталоге, унаследуют свою группу из этого каталога. (Поведение по умолчанию — использовать основную группу эффективного пользователя при установке группы новых файлов и каталогов, за исключением систем на основе BSD, которые ведут себя так, как будто бит setgid всегда установлен для всех каталогов (см. Setuid ).)
  • Режим sticky (также известный как текстовый режим). Классическое поведение бита sticky в исполняемых файлах заключается в том, чтобы побуждать ядро ​​сохранять полученный образ процесса в памяти после завершения; однако такое использование бита sticky теперь ограничено только меньшинством операционных систем типа unix ( HP-UX и UnixWare ). В каталоге разрешение sticky не позволяет пользователям переименовывать, перемещать или удалять содержащиеся в нем файлы, принадлежащие другим пользователям, даже если у них есть разрешение на запись в каталог. Только владелец каталога и суперпользователь освобождены от этого.

Эти дополнительные режимы также называются битом setuid , битом setgid и битом sticky , поскольку каждый из них занимает только один бит.

Обозначение традиционных разрешений Unix

Символическое обозначение

Разрешения Unix представлены либо в символической, либо в восьмеричной системе счисления.

Наиболее распространенной формой, используемой командой ls -l, является символическая запись .

Три триады разрешения
первая триадачто может сделать владелец
вторая триадачто могут делать члены группы
третья триадачто могут делать другие пользователи
Каждая триада
первый персонажr: читаемо
второй персонажw: доступен для записи
третий персонажx: исполняемый
sили t: setuid / setgid или sticky (также исполняемый)
Sили T: setuid/setgid или sticky (не исполняемый)

Первый символ на lsдисплее указывает на тип файла и не связан с разрешениями. Остальные девять символов находятся в трех наборах, каждый из которых представляет класс разрешений в виде трех символов. Первый набор представляет класс пользователя . Второй набор представляет класс группы . Третий набор представляет класс других .

Каждый из трех символов представляет разрешения на чтение, запись и выполнение:

  • rесли чтение разрешено, -если нет.
  • wесли разрешено писать, -если нет.
  • xесли казнь разрешена, -если нет.

Ниже приведены некоторые примеры символических обозначений:

  • -rwxr-xr-x: обычный файл, класс пользователя которого имеет полные права доступа, а классы группы и другие имеют только права доступа на чтение и выполнение.
  • crw-rw-r--: специальный символьный файл, классы пользователей и групп которого имеют разрешения на чтение и запись, а классы других имеют только разрешение на чтение.
  • dr-x------: каталог, пользовательский класс которого имеет разрешения на чтение и выполнение, а групповые и другие классы не имеют разрешений.

В некоторых системах разрешений дополнительные символы на ls -lдисплее представляют дополнительные функции разрешения:

  • Суффикс + (плюс) указывает на список контроля доступа, который может контролировать дополнительные разрешения.
  • . (точка) суффикс указывает на наличие контекста SELinux . Подробности можно узнать с помощью команды ls -Z.
  • Суффикс @ указывает на наличие расширенных атрибутов файла .

Для представления атрибутов setuid , setgid и sticky или text изменяется исполняемый символ ( xили -). Хотя эти атрибуты влияют на весь файл, а не только на пользователей в одном классе, атрибут setuid изменяет исполняемый символ в триаде для пользователя, атрибут setgid изменяет исполняемый символ в триаде для группы, а атрибут sticky или text изменяет исполняемый символ в триаде для других. Для атрибутов setuid или setgid в первой или второй триаде становится xи sстановится -. SДля атрибута sticky или text в третьей триаде xстановится tи -становится T. Вот пример:

  • -rwsr-Sr-t: файл, пользовательский класс которого имеет разрешения на чтение, запись и выполнение; групповой класс которого имеет разрешения на чтение; другие классы которого имеют разрешения на чтение и выполнение; и у которого установлены атрибуты setuid , setgid и sticky .

Числовое обозначение

Другим методом представления разрешений Unix является восьмеричная (основание 8) нотация, как показано stat -c %a. Эта нотация состоит как минимум из трех цифр. Каждая из трех крайних правых цифр представляет отдельный компонент разрешений: владельца, группу и других. (Если присутствует четвертая цифра, крайняя левая (старшая) цифра адресует три дополнительных атрибута: бит setuid , бит setgid и бит sticky .)

Каждая из этих цифр является суммой своих компонентных битов в двоичной системе счисления . В результате определенные биты добавляются к сумме, как она представлена ​​цифрой:

  • Прочитанный бит добавляет 4 к своей сумме (в двоичном формате 100),
  • Бит записи добавляет 2 к своей сумме (в двоичном формате 010), и
  • Бит выполнения добавляет 1 к своей общей сумме (в двоичном формате 001).

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

Ниже приведены примеры из раздела символической записи, приведенные в восьмеричной системе счисления:

Символическое
обозначение
Числовое
обозначение
Английский
----------0000нет разрешений
-rwx------0700чтение, запись и выполнение только для владельца
-rwxrwx---0770чтение, запись и выполнение для владельца и группы
-rwxrwxrwx0777чтение, запись и выполнение для владельца, группы и других
---x--x--x0111выполнять
--w--w--w-0222писать
--wx-wx-wx0333написать и выполнить
-r--r--r--0444читать
-r-xr-xr-x0555прочитать и выполнить
-rw-rw-rw-0666читать и писать
-rwxr-----0740владелец может читать, писать и выполнять; группа может только читать; другие не имеют разрешений

Пользователь частной группы

Некоторые системы отходят от традиционной модели пользователей и групп POSIX, создавая новую группу – «частную группу пользователей» – для каждого пользователя. Предполагая, что каждый пользователь является единственным членом своей частной группы пользователей, эта схема позволяет использовать umask 002, не позволяя другим пользователям записывать в недавно созданные файлы в обычных каталогах, поскольку такие файлы назначаются частной группе создающего пользователя. Однако, когда желательно совместное использование файлов, администратор может создать группу, содержащую нужных пользователей, создать доступный для записи группой каталог, назначенный новой группе, и, что самое важное, сделать каталог setgid. Если сделать его setgid, файлы, созданные в нем, будут назначены той же группе, что и каталог, а umask 002 (включенный с помощью частных групп пользователей) гарантирует, что другие члены группы смогут записывать в эти файлы. [11] [12]

Смотрите также

Ссылки

  1. ^ «Разрешения для файлов и папок». Microsoft. 9 декабря 2009 г.
  2. ^ "Документация OpenVMS". Архивировано из оригинала 2012-03-05 . Получено 2009-06-06 .
  3. ^ "Руководство по администрированию Oracle Solaris ZFS" (PDF) . Сентябрь 2010 г.
  4. ^ "Собственные списки контроля доступа NFSv4 в Linux". Архивировано из оригинала 2008-10-12 . Получено 2010-05-04 .
  5. ^ «NFSv4_ACLs – FreeBSD Wiki».
  6. ^ «Руководство пользователя FreeNAS 9.1.1» (PDF) . 2013.
  7. ^ «Центр знаний IBM».
  8. ^ "HarmonyOS Distributed File System Development Guide". Substack . LivingInHarmony Blog. 13 марта 2024 г. Получено 13 марта 2024 г.
  9. ^ "Определения, 3.175 Биты разрешений файла". pubs.opengroup.org . 2018-07-22 . Получено 2023-06-24 .
  10. Хэтч, Брайт. «Linux File Permission Confusion, часть 2», «Hacking Linux Exposed», 24 апреля 2003 г., дата обращения 6 июля 2011 г.
  11. ^ Эпштейн, Брайан. «Как и почему существуют частные группы пользователей в Unix». security.ias.edu . Институт перспективных исследований сетевой безопасности. Архивировано из оригинала 8 августа 2014 г. Получено 5 августа 2014 г.
  12. ^ "Red Hat Enterprise Linux 7 System Administrator's Guide, 4.3.4 Создание групповых каталогов". Red Hat Customer Portal . Red Hat.
  • «Linux Cookbook: Группы и как в них работать» Майкла Штутца, 2004 г.
Получено с "https://en.wikipedia.org/w/index.php?title=File-system_permissions&oldid=1263274066"