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

21

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

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

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

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

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

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

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

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

linux permissions Юваль
источник
1
Я не очень понимаю, почему вы думаете, что групповых разрешений будет достаточно. Представьте себе ситуацию, когда вы хотите, чтобы ваши разработчики имели свои собственные личные файлы (конфигурации и т. Д.), Но также хотели бы позволить им обмениваться кодом друг с другом. Наличие devsгруппы позволяет это сделать.
Крис Даун
@ChrisDown Он говорит, что вы сделаете пользователя fooчленом группы fooи devsназначите общие файлы для devгруппы и личные файлы для fooгруппы
Майкл Мрозек
4
Пока вы занимаетесь этим, зачем нужны мировые разрешения, а не просто группа «все», членом которой являются все? Ответ заключается в том, что пользователь / группа / другие настройки разрешений были изобретены до ACL.
Random832

Ответы:

24

история

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

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

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

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

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

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

Простота

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

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

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

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

Жиль "ТАК - перестань быть злым"
источник
Отличный ответ, и мне понравилось узнавать о пожилом мужчине. Однако у меня есть некоторые сомнения по поводу того, что вы сказали. Более простая система, которая на самом деле может делать почти (если не точно) столько же, сколько ACL, позволяет каждому из разрешений 'rwx' переносить группу (а не наоборот). То есть у вас будет группа чтения, группа записи и группа выполнения. Если это действительно необходимо для ОС, вы можете прикрепить владельца к файлу. Таким образом, вы также можете указать специальную группу «владелец» и группу «все». Помимо иерархии, я думаю, что это охватывает все, включая простоту и ортогональность.
Юваль
1
@Yuval То, что вы описываете, это система ACL - такая же, как в Linux, за исключением того, что у вас нет прямой возможности назначать разрешения пользователю.
Жиль "ТАК - перестань быть злым"
Это может быть. Я попытался подчеркнуть, что в настоящее время каждая запись в файле содержит два идентификатора (группа, владелец) и битовую маску. Разве не было бы более эффективно (опять же, аргумент цена / прибыль) просто держать четыре идентификатора? (выполнить группу, прочитать группу, написать группу, владельца)
Юваль
@Yuval Почему четыре удостоверения личности? Это было бы намного более ограничительным, чем ACL (потому что вам нужен root, чтобы определить группу для каждого набора), и вряд ли было бы более гибким, чем текущие разрешения Unix (отличить чтение от выполнения крайне редко, а для записи вам часто хотелось бы объединение группы чтения и группы записи). Если вы разрешаете список групп для каждого разрешения и список пользователей для правильной оценки (поскольку не всегда есть правильная группа, не во всех системах есть группа на пользователя), вы в основном получаете списки управления доступом Solaris / Linux.
Жиль "ТАК - перестань быть злым"
Вы утверждаете, что то, что я описал, является ACL, но это означает, что текущая схема разрешений Linux является списком ACL для инвалидов, в котором разрешено иметь только одну пользовательскую запись, одну групповую запись и одну запись для всех (для использования Windows Lingo). Я предложил изменить инвалидность, изменив семантику. Вместо того, чтобы прописывать сущности, прописывайте разрешения. Это может быть то, как традиционные ACL реализованы - я не знаю. Дело в том, что это минимальная стоимость, с точки зрения хранения и простоты, по сравнению с текущим состоянием, все еще ортогональная, но с полной выразительной силой ACL.
Ювал
10

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

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

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

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

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

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

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

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

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

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

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

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

Чарльз Бойд
источник
1
Я думаю, что "группа / владелец" была опечаткой, предназначенной, чтобы быть "группой / другим"
Random832
Ах, вы, вероятно, правы! В этом случае я добавлю еще один контрпример.
Чарльз Бойд
3
Как вы можете прочитать The UNIX Time-Sharing System, написанное Деннисом М. Ритчи и Кеном Томсоном в 1974 году, изначально было 7 битов для разрешений: Also given for new files is a set of seven protection bits. Six of these specify independently read, write, and execute permission for the owner of the file and for all other users.(седьмой бит был setuidбитом).
Карлос Кампдеррос
4

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

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

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

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

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

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

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

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

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

BillThor
источник
3

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

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

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

Random832
источник