Существует ли причина, почему полномочия 'владельца' существуют? Разве полномочия группы не достаточно?

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

user/group/other полномочия на файле являются частью исходного дизайна Unix.

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

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

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

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

Править: Предположим, Вы имели в виду здесь group/other полномочия - все, что было бы необходимо, затем я предлагаю создать некоторый способ управлять криптографическими ключами или способом, которым только правильные пользователи могут получить доступ к своей почтовой шпульке. Существуют случаи, где закрытому ключу, возможно, понадобится строго user:user владение, но другие случаи, где имеет смысл давать его user:group владение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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