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

Как правило, файловая система содержит настройки разрешений для каждого объекта, будь то файл или каталог . Эти настройки определяют, разрешён или запрещён доступ к объектам файловой системы. Часто настройки позволяют управлять доступом на основе таких действий, как чтение, изменение, просмотр и выполнение^[англ.], а также для разных пользователей и групп пользователей.

Одна из устоявшихся технологий была разработана для Unix, а затем кодифицирована стандартом POSIX. Другая распространённая технология — это список контроля доступа (access-control list, ACL) , имеющий множество вариантов, реализованных в файловых системах, и один из них кодифицирован POSIX. Поскольку POSIX определяет как старую технологию на основе Unix, так и ACL, первая для ясности называется традиционными разрешениями POSIX, хотя этот термин не является общеизвестным.

Интерфейс пользователя, управляемый разрешениями, адаптирует доступную пользователю функциональность в зависимости от разрешений для объектов файловой системы. Например, интерфейс может скрывать пункты меню, которые не разрешены на основе данных объекту разрешений.

История

CTSS

Ранняя система разделения времени, Compatible Time-Sharing System^[англ.] (Совместимая Система Разделения времени, CTSS), позволяла работать нескольким пользователям одновременно. У каждой учётной записи пользователя были «номер задачи» и «номер программиста»^[1].

Первая версия файловой системы CTSS поддерживала для файла всего два режима «только для чтения»:

один мог быть снят пользователем самостоятельно

другой мог быть снят только с помощью специальных карточек, подаваемых в компьютерный центр^[2].

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

Во второй версии файловой системы появились отдельные биты разрешений для режимов «только для чтения» и «только для записи». Последний позволял только дописывать данные в файл. Также был добавлен бит «приватный», который разрешал доступ к файлу только его автору, и бит «защищённый», который позволял только автору файла изменять его разрешения^[4].

Multics

В системе разделения времени Multics у пользователей есть «идентификатор пользователя» (Person_id), a у проектов — «идентификатор проекта» (Project_id). Пользователь входит в систему, используя свой Person_id и Project_id. Файл имеет список контроля доступа (ACL), с записями, содержащими Person_id или «*», Project_id или «*»", а также тег экземпляра (instance tag) или «*». Тег экземпляра обозначает тип процесса. Например, «a» rозначает процесс из обычной интерактивной сессии. Записи в ACL сравниваются с Person_id, Project_id и тегом экземпляра процесса. Символ «*» является подстановочным знаком, который соответствует любому Person_id, Project_id или тегу экземпляра. Используется та запись ACL, которая соответствует наименьшему количеству подстановочных (звёздочек)^[5].

ACL для файла имеет права доступа «read», «write» и «execute». ACL для каталога определяет права доступа «status» (статус, разрешает чтение атрибутов файлов и подкаталогов в каталоге), «modify» (изменение, разрешает изменение атрибутов файлов и подкаталогов в каталоге, а также удаление элементов из каталога) и «append» (добавление, разрешает добавление новых элементов в каталог)^[6].

TENEX

В системе TENEX^[англ.] пользователь принадлежит набору групп^[7].

Файл или каталог имеет набор битов разрешений: шесть битов для владельца файла или каталога, шесть битов для других пользователей из группы файла или каталога и шесть битов для остальных пользователей. Биты разрешений для файла: «read», «write», «execute», «append» и «каждая страница файла имеет собственные разрешения», при этом шестой бит не используется. Биты разрешений для каталога: «доступ разрешён» (если не установлено, доступ к каталогу запрещён), «файлы в каталоге могут быть открыты» (с учетом битов разрешений файла), «функции владельца могут выполняться без пароля файла» и «файлы могут быть добавлены в каталог», пятый и шестой биты не используются^[8].

TOPS-10

В TOPS-10 учётная запись пользователя имеет номер программиста и номер проекта.

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

• 7 - нет прав доступа, за исключением того, что владелец может просматривать файл для изменения его разрешений
• 6 - только выполнение
• 5 - чтение и выполнение
• 4 - добавление, чтение и выполнение
• 3 - обновление, добавление, чтение и выполнение
• 2 - запись, обновление, добавление, чтение и выполнение
• 1 - переименование, запись, обновление, добавление, чтение и выполнение
• 0 - изменение разрешений, переименование, запись, обновление, добавление, чтение и выполнение.

Владелец всегда имеет право изменять разрешения^[9].

UNIX и подобные системы

Файлы в первом издании Unix (v1) имели пять битов разрешений:

• запись, не владелец
• чтение, не владелец
• запись, владелец
• чтение, владелец
• исполняемый

и set-UID бит^[10]. Понятия группы не было, и это продолжалось вплоть до третьей версии (v3)^[11]. В четвёртой версии (v4) было введено понятие групп и файлы в этой версии имели девять бит разрешений:

• чтение, владелец
• запись, владелец
• исполняемый, владелец;
• чтение, группа
• запись, группа
• исполняемый, группа;
• чтение, другие
• запись, другие
• исполняемый, другие;

а также биты set-UID и set-GID^[12]. Это тот же набор разрешений, который указан в POSIX и предоставляется современными системами Unix и Unix-подобными системами.

Примеры

Системы управления правами доступа к файлам реализованы множеством способов. Ниже приведены некоторые из наиболее известных.

NTFS , используемая во многих версиях Windows, включая Windows 11, применяет списки контроля доступа (ACL) для управления доступом на основе разрешений. Списки ACL в NTFS считаются мощными, но сложными^[13].

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

FreeBSD поддерживает POSIX.1e ACL на UFS, а также NFSv4 ACL на UFS и ZFS^[15][16].

HFS и её преемница HFS+, реализованные в классической операционной системе Mac OS, не поддерживают права доступа.

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

FAT (оригинальная версия) имеет атрибут «только для чтения» для каждого файла, который применяется ко всем пользователям.

OpenVMS определяет четыре функции доступа: read, write, execute и delete, а также выбор пользователей: система, владелец, группа и все, при этом «все» включает в себя группу, которая, в свою очередь, включает владельца, а «система» выбирает системных пользователей. Такая конструкция схожа с Unix, но имеет заметные расширения: дополнительная функция — удаление, и дополнительный выбор пользователя — система^[18]. Списки контроля доступа (ACL) поддерживаются в VMS начиная с версии 4.0^[19].

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

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

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

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

Традиционные разрешения POSIX

Традиционно права доступа к файлам в файловых системах на базе Unix определяются стандартом POSIX.1-2017^[23]. Он устанавливает три класса пользователей (владелец, группа и остальные) для назначения прав и три операции (чтение, запись, выполнение), которые могут быть разрешены или запрещены для каждого класса. При создании файла его права доступа по умолчанию устанавливаются с помощью команды umask.

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

Классы

Классы определяют, как права доступа соотносятся с пользователем. Права класса пользователь применяются к пользователю, которому принадлежит файл. Права класса группа применяются к пользователю из группы^[англ.], которой принадлежит файл. Класс остальные применяется ко всем остальным пользователям.

Эффективные права доступа — это права того класса, к которому пользователь относится в первую очередь, учитывая порядок: владелец, группа, затем остальные. Например, владелец файла имеет эффективные права класса «владелец», даже если он также входит в группу, которой принадлежит файл.

Разрешения

Следующие разрешения предоставляют соответствующие операции над файлами и каталогами:

Read (r)

• Для файлов: даёт возможность читать содержимое файла (но не его имя или метаданные, которые определяются правами доступа к родительскому каталогу).
• Для каталогов: даёт возможность читать имена файлов и подкаталогов, содержащихся в нем, но не получать доступ к их метаданным (inode) и, следовательно, к их содержимому, что определяется правом на выполнение для каталога.

Write (w)

• Для файлов: даёт возможность изменять содержимое файла.
• Для каталогов: даёт возможность изменять элементы каталога, что позволяет создание, удаление и переименование файлов и подкаталогов.
  • Для выполнения этого требуется разрешение execute, чтобы получить метаданные (inode) всех содержащихся в каталоге файлов. Таким образом, без разрешения execute разрешение write бессысленно.

Execute (x)

• Для файлов: даёт возможность выполнить файл. Это разрешение должно быть установлено для выполняемых программ, чтобы иметь возможность их запускать.
  • Для выполнения этого требуется разрешение read.
• Для каталогов: даёт возможность читать метаданнные содержащихся в каталоге файлови подкаталогов, если их имена известны, но не позволяет читать их имена. Каталог без разрешения execute блокирует чтение и запись содержащихся в каталоге файлов и подкаталогов.
  • Каталог с разрешением execute, но без разрешения read делает доступ к содержимому файлов и подкаталогов «игрой на угадывание имён».

Общие требования к доступу внутри каталогов

Для доступа к содержимому файла или подкаталога внутри другого каталога необходимо:

1. Знать его имя. Это имя можно узнать, если у родительского каталога есть разрешение read (на чтение, или можно попытаться угадать).
2. Иметь разрешение execute (на выполнение) для родительского каталога, чтобы получить доступ к файлу или inode подкаталога.
3. Иметь соответствующие разрешения на чтение, запись или выполнение для самого файла или подкаталога.

Сводка требований к разрешениям для файловых операций

Чтобы читать из файла, нужно иметь:

• Разрешение read (на чтение).
• Разрешение execute (на выполнение) для его родительского каталога.

Чтобы записывать в файл, нужно иметь:

• Разрешение write (на запись).
• Разрешение execute (на выполнение) для его родительского каталога.

Чтобы запустить файл, нужно иметь:

• Разрешения read и execute.
• Разрешение execute (на выполнение) для его родительского каталога

Чтобы узнать имя файла, нужно иметь:

• Разрешение read (на чтение) для его родительского каталога .

Чтобы добавить, удалить или переименовать файл, нужно иметь:

• Разрешения write и execute для его родительского каталога.

Замечания

Метаданные файла или каталога обычно включают идентификатор inode, тип файла, размер, владельца (имя пользователя и UID) и биты разрешений.

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

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

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

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

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

Представление

Права доступа обычно представлены в символьной или восьмеричной нотации.

Символьная нотация

Символьная нотация используется при запросе длинного вывода в команде ls -l.

Первый символ вывода указывает тип файла Unix^[англ.], который не является разрешением, хотя и находится рядом с информацией о разрешениях. Остальные девять символов представляют собой предоставленные права для классов пользователя, группы и остальных, сгруппированные по операциям: чтение, запись и выполнение. Операция запрещена, если она обозначена тире, и разрешена, если обозначена буквой r (чтение), w (запись) или x (выполнение).

Примеры:

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

Для обозначения атрибутов setuid, setgid и sticky/text изменяется символ в третьей позиции для каждого класса. Хотя эта позиция обычно предназначена только для прав на выполнение, эти атрибуты влияют на файл независимо от класса.

Атрибут setuid изменяет символ выполнения для класса пользователя. Cимвол «x» заменяется на «s», а символ «-» на «S».

Атрибут setgid изменяет символ выполнения для класса группы. Cимвол «x» заменяется на «s», а символ «-» на «S».

Атрибут sticky text изменяет символ выполнения для класса остальных. Символ «x» заменяется на «t», а символ «-» на «T».

Например, запись -rwsr-Sr-t означает, что это обычный файл, у которого

• класс пользователя имеет права на чтение, запись и выполнение
• класс группы имеет право на чтение
• класс остальных имеет права на чтение и выполнение
• а также установлены атрибуты setuid, setgid и sticky.

Некоторые системы показывают дополнительные разрешения:

• Суффикс + означает список управления доступом, который может управлять дополнительными разрешениями
• Суффикс . означает, что присутствует контекст SELinux. Детали можно получить командой ls -Z
• Суффикс @ означает присутствие расширенных атрибутов файла^[англ.]

Восьмеричная нотация

Часто разрешения показываются в восьмеричной нотации. Например, с помощью команды stat -c %a. Нотация состоит как минимум из трёх цифр. Последние три цифры представляют права для каждой категории: владелец, группа и остальные: владелец, группа и остальные. Если присутствует четвертая цифра, самая левая обозначает три специальных атрибута: setuid, setgid и sticky.

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

• Чтение: двоичное 100, восьмеричное 4
• Запись: двоичное 010, восьмеричное 2
• Выполнение: двоичное 001, восьмеричное 1

Значение прав для категории является суммой или, альтернативно, логическим ИЛИ разрешений.

Примеры:

Символическая нотация	Восьмеричная нотация	Описание
----------	0000	никаких прав никому
-rwx------	0700	чтение, запись и исполнение только для владельца
-rwxrwx---	0770	чтение, запись и исполнение для владельца и группы
-rwxrwxrwx	0777	чтение, запись и исполнение для владельца, группы и остальных
-rwxr-----	0740	владелец может читать, писать и исполнять; группа может только читать; остальные не имеют никаких прав

Приватная группа пользователя

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

См. также

• chattr или chflags — Изменить атрибуты или флаги, включая ье, которые ограничивают доступ
• chmod — Команда оболочки для изменения прав доступа к файлу
• Сравнение файловых систем