Jump to content

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

(Перенаправлено из «Разрешения на файл »)

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

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

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

[ редактировать ]

Исходная файловая система Таблицы размещения файлов имеет атрибут «только для чтения» для каждого файла.

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

OpenVMS использует схему разрешений, аналогичную схеме Unix. Существует четыре категории (система, владелец, группа и мир) и четыре типа разрешений доступа (Чтение, Запись, Выполнение и Удаление). Категории не являются взаимно непересекающимися: Мир включает в себя Группу, которая, в свою очередь, включает Владельца. В категорию «Система» самостоятельно входят пользователи системы. [2]

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

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

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

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

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

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

Файловая система AmigaOS, AmigaDOS, поддерживает систему разрешений, относительно продвинутую для однопользовательской ОС. В AmigaOS 1.x файлы имели разрешения/флаги «Архивирование», «Чтение», «Запись», «Выполнение» и «Удаление» (вместе известные как ARWED). В AmigaOS 2.x и выше были добавлены дополнительные разрешения/флаги Hold, Script и Pure.

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

POSIX-разрешения

[ редактировать ]

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

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

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

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

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

Разрешения

[ редактировать ]

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

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

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

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

Изменение поведения разрешений с помощью битов setuid, setgid и Sticky.

[ редактировать ]

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

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

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

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

[ редактировать ]

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

[ редактировать ]

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

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

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

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

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

  • 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. Для атрибута «липкий» или «текст» в третьей триаде x становится t и - становится T. Вот пример:

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

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

[ редактировать ]

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

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

  • Бит чтения добавляет 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, создавая новую группу — «частную группу пользователей» — для каждого пользователя. Предполагая, что каждый пользователь является единственным членом своей частной группы пользователей, эта схема позволяет использовать маску 002, не позволяя другим пользователям записывать вновь созданные файлы в обычных каталогах, поскольку такие файлы назначаются частной группе создающего пользователя. Однако, если совместное использование файлов желательно, администратор может создать группу, содержащую нужных пользователей, создать каталог с возможностью записи для группы, назначенный новой группе, и, что наиболее важно, сделать каталог установленным. Установка setgid приведет к тому, что созданные в нем файлы будут отнесены к той же группе, что и каталог, а маска 002 (включаемая с помощью частных групп пользователей) гарантирует, что другие члены группы смогут писать в эти файлы. [11] [12]

См. также

[ редактировать ]
  1. ^ «Разрешения для файлов и папок» . Майкрософт.
  2. ^ «Документация OpenVMS» . Архивировано из оригинала 05 марта 2012 г. Проверено 6 июня 2009 г.
  3. ^ «Руководство по администрированию Oracle Solaris ZFS» (PDF) . Сентябрь 2010 г.
  4. ^ «Встроенные списки управления доступом NFSv4 в Linux» . Архивировано из оригинала 12 октября 2008 г. Проверено 4 мая 2010 г.
  5. ^ «NFSv4_ACL — FreeBSD Wiki» .
  6. ^ «Руководство пользователя FreeNAS 9.1.1» (PDF) . 2013.
  7. ^ «Центр знаний IBM» .
  8. ^ «Руководство по разработке распределенной файловой системы HarmonyOS» . Подстек . Блог LivingInHarmony . Проверено 13 марта 2024 г.
  9. ^ «Определения, 3,175 бит разрешения файла» . pubs.opengroup.org . 22 июля 2018 г. Проверено 24 июня 2023 г.
  10. ^ Хэтч, Брай. «Замешательство в разрешениях файлов Linux, часть 2» , «Hacking Linux Expose», 24 апреля 2003 г., по состоянию на 6 июля 2011 г.
  11. ^ Эпштейн, Брайан. «Как и почему создаются частные группы пользователей в Unix» . Security.ias.edu . Институт перспективных исследований сетевой безопасности. Архивировано из оригинала 8 августа 2014 года . Проверено 5 августа 2014 г.
  12. ^ «Руководство системного администратора Red Hat Enterprise Linux 7, 4.3.4 Создание групповых каталогов» . Портал для клиентов Red Hat . Красная шляпа.
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: d75f49d4cdb442a88817bb7d987cff71__1720341000
URL1:https://arc.ask3.ru/arc/aa/d7/71/d75f49d4cdb442a88817bb7d987cff71.html
Заголовок, (Title) документа по адресу, URL1:
File-system permissions - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)