Есть ли причина, по которой существуют права «владельца»? Разве групповых разрешений недостаточно?

Я думаю, что я довольно понимаю, как разрешения файлов работают в Linux. Однако я не очень понимаю, почему они делятся на три уровня, а не на два.

Я хотел бы, чтобы ответы на следующие вопросы:

• Это намеренный дизайн или патч? То есть были ли разрешения владельца / группы разработаны и созданы вместе с каким-либо обоснованием, или они приходили одно за другим, чтобы ответить на потребность?
• Существует ли сценарий, в котором схема пользователя / группы / другого полезна, но схемы группы / другого недостаточно?

Ответы на первые должны цитировать либо учебники, либо официальные доски обсуждений.

Варианты использования, которые я рассмотрел:

• личные файлы - очень легко получить, создав группу для каждого пользователя, что часто делается, как во многих системах.
• разрешение на запись в файл только владельцу (например, системному сервису), чтение только определенной группе и запрет на любой другой доступ - проблема этого примера в том, что, как только для группы требуется доступ на запись, пользователь / group / other терпит неудачу с этим. Ответом для обоих является использование ACL, и не оправдывает, IMHO, наличие прав владельца.

NB. Я уточнил этот вопрос после того, как закрыл вопрос в superuser.com .

ИЗМЕНИТЬ исправлено "но схемы группы / владельца не хватит" до "... группа / другое ...".

история

Изначально Unix имел разрешения только для пользователя-владельца и для других пользователей: не было групп. См. Документацию Unix версии 1, в частности chmod(1). Таким образом, обратная совместимость, если не что иное, требует прав для пользователя-владельца.

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

Выразительная сила

Наличие трех разрешений для файла позволяет получить более детальные разрешения, чем только два, с очень низкой стоимостью (намного ниже, чем списки ACL). Например, файл может иметь режим rw-r-----: доступный для записи только пользователю-владельцу, доступный для чтения группе.

Другой вариант использования - исполняемые файлы setuid, которые могут выполняться только одной группой. Например, программа с режимом, которым rwsr-x---владеют, root:adminпозволяет только пользователям в adminгруппе запускать эту программу от имени пользователя root.

«Есть разрешения, которые эта схема не может выразить» - это ужасный аргумент против этого. Применимый критерий: достаточно ли общепризнанных случаев, которые оправдывают стоимость? В этом случае стоимость минимальна, особенно с учетом других причин для пользователя / группы / другого триптиха.

Простота

Наличие одной группы на пользователя имеет небольшие, но незначительные накладные расходы на управление. Хорошо, что крайне распространенный случай частного файла не зависит от этого. Приложение, которое создает личный файл (например, программа доставки электронной почты), знает, что все, что ему нужно сделать, это дать файлу режим 600. Ему не нужно проходить через базу данных группы в поисках группы, которая содержит только пользователя - и что делать, если такой группы нет или их больше одной?

Если исходить из другого направления, предположим, что вы видите файл и хотите проверить его разрешения (т. Е. Проверить, соответствуют ли они тем, кем они должны быть). Намного проще, когда вы можете перейти «только для пользователя, хорошо, далее», чем когда вам нужно проследить через определения групп. (Такая сложность является проблемой систем, которые интенсивно используют расширенные функции, такие как ACL или возможности.)

Ортогональность

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

Это намеренный дизайн или патч? То есть были ли разрешения владельца / группы разработаны и созданы вместе с каким-либо обоснованием, или они приходили одно за другим, чтобы ответить на потребность?

Пользователь / группа / другие разрешения для файла являются частью оригинального проекта Unix.

Существует ли сценарий, в котором схема пользователя / группы / другого полезна, но схемы группы / владельца будет недостаточно?

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

Пример. Возможно, вы захотите предоставить некоторым двоичным файлам / сценариям доступ к системе только для выполнения otherи оставить доступ для чтения / записи ограниченным root.

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

РЕДАКТИРОВАТЬ: Предположим, что вы имели в виду здесь group/otherразрешения, это все, что нужно, тогда я предлагаю разработать какой-то способ управления криптографическими ключами или способ, которым только нужные пользователи могут получить доступ к своей почтовой папке. Есть случаи, когда закрытый ключ может нуждаться в строгом user:userвладении, но в других случаях имеет смысл передать его в user:groupсобственность.

личные файлы - очень легко получить, создав группу для каждого пользователя, что часто делается, как во многих системах.

Конечно, это легко сделать, но это так же легко сделать с существованием otherгруппы ...

разрешение на запись в файл только владельцу (например, системному сервису), чтение только определенной группе и запрет на любой другой доступ - проблема этого примера в том, что, как только для группы требуется доступ на запись, пользователь / group / other терпит неудачу с этим. Ответом для обоих является использование ACL, и не оправдывает, IMHO, наличие прав владельца.

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

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

Это намеренный дизайн или патч? То есть были ли разрешения владельца / группы разработаны и созданы вместе с каким-либо обоснованием, или они приходили одно за другим, чтобы ответить на потребность?

Да, это преднамеренный дизайн, который присутствует в UNIX с первых дней. Он был реализован в системах, где память измерялась в килобайтах, а процессоры были очень медленными по современным стандартам. Размер и скорость таких поисков были важны. ACL потребовали бы больше места и были бы медленнее. Функционально everyoneгруппа представлена ​​другими флагами безопасности.

Существует ли сценарий, в котором схема пользователя / группы / другого полезна, но схемы группы / владельца будет недостаточно?

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

• 600или 400: доступ только для пользователя (и да, я даю пользователю доступ только для чтения).
• 640или 660: доступ пользователя и группы.
• 644, 666Или 664: Пользователь, группа, и другой доступ. Любая двухуровневая схема разрешений может обрабатывать только два из этих трех случаев. Третий требует ACL.

Для каталогов и программ я обычно использую:

• 700или 500: только пользовательский доступ
• 750или 710: только групповой доступ
• 755, 777, 775, Или 751: Пользователь, группа, и другой доступ. Те же комментарии применимы, что и к файлам.

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

Как было отмечено выше, очень легко перечислить разрешение в списке каталога. Если ACL не используются, я могу проверять права доступа только с помощью списка каталогов. Когда я работаю с системами на основе ACL, мне очень трудно проверять или проверять разрешения.

Система полномочий пользователя / группы / другого была разработана до того, как были изобретены списки ACL. Это восходит к ранним временам UNIX, поэтому вы не можете сказать, что проблема должна быть решена с помощью ACL. Даже если концепция ACL кажется очевидной, это потребовало бы значительных [на день] дополнительных затрат на хранение и управление переменным количеством информации о разрешениях для каждого файла, а не фиксированной суммой.

Использование ACL для всего также означает, что у вас нет четко определенного подмножества информации о разрешениях, которая может быть показана «с первого взгляда». Выходные данные для ls -lпоказывают стандартные (пользователь / группа / другие) разрешения, имя пользователя и группы и дополнительную запись (например, +или @знак) для записей, с которыми связан ACL, все в одной строке. Ваша система будет требовать, чтобы она идентифицировала «две верхние» группы в ACL, чтобы обеспечить эквивалентную функциональность.

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