☰

указание сложных прав доступа к файлам и папкам в unix

tag-icon • tag-icon permissions unix nfs file-permissions access-control-list
указание сложных прав доступа к файлам и папкам в unix

На работе я руковожу группой, отвечающей за управление данными и безопасность. Нам нужно указать сложные разрешения для файлов и папок, выходящие за рамки простого стандартного пользователя/группы/мира rwx. Исследования показывают, что это можно сделать с помощью расширенных атрибутов файлов (команды setfacl, getfacl) на файловерах, работающих под управлением NFSv4. Файлерами на работе используется NFSv3. Когда я спрашиваю ИТ-группу о переходе, они всегда отвечают: «Это слишком медленно, слишком сложно, небезопасно или не стабильно и т. д.» для перехода на NFSv4, не предоставляя данных или сроков для обоснования заявлений. В результате мы создаем несколько копий данных, где в каталоге A есть файлы, которые может просматривать группа A, а в каталоге B есть файлы, которые может просматривать группа B.

Меня интересуют несколько вещей:

  1. верны ли утверждения? Сильно ли влияет на производительность преобразование из NFSv3 в NFSv4 с включенными расширенными атрибутами файлов? Есть ли другие моменты, которые следует учитывать? Например, я предполагаю, что некоторые приложения могут быть не закодированы для правильной интерпретации этих расширенных атрибутов файлов.
  2. Помимо acls на NFSv4, есть ли другое решение или метод применения сложных разрешений? Большинство рабочих машин работают под управлением SLES11 или SLES12.

Буду признателен за любую помощь или направление, которые вы можете предложить...спасибо!

решение1

NFS 4 может быть намного безопаснее и он, безусловно, стабилен, доступен с 2003 года, если я правильно помню. Есть и более новые версии, 4.1 и 4.2. Его довольно легко обновить, если вы не включаете какие-либо расширенные функции.

  1. Производительность может быть немного лучше на nfs 3 из-за использования udp и tcp; nfs 4 — только tcp. Но это не имеет большого значения в большинстве сценариев. На самом деле это можно компенсировать, потому что в tcp при потере пакетов только эти потерянные пакеты передаются повторно, в отличие от udp. В nfs 4 также есть делегирование, которое может повысить производительность. Шифрование может сильно повлиять на производительность, но это выбор, не обязательно использовать более высокие стандарты безопасности на nfs 4, но они доступны при необходимости.
    Я не могу сказать ничего о несовместимости приложений с использованием nfs v4. Я использовал его для операций копирования-перемещения файлов и потоковой передачи видео без проблем.

  2. Не могу дать вам точный ответ на этот вопрос, хотя я думаю, что отсутствие альтернатив породило nfs v4. SMB/CIFS можно использовать; я не считаю его родной альтернативой, поскольку это протокол Windows, однако реализация UNIX/Linux превосходна. Хотя я предполагаю, что реализовать его на серверах и клиентах Linux будет сложнее, чем nfs v4.

Причиной того, что ваша ИТ-команда не хочет переходить на v4, может быть совместимость и поддержка ОС: и серверы, и клиенты должны поддерживать ее. Возможно, есть старые ОС, например SLES 11 без SP, которые не поддерживаются SuSE, и они предпочитают избегать изменения настроек на них.

Также есть возможность поделиться с помощью nfs v3 и v4. Вы можете протестировать его на некоторых каталогах, прежде чем полностью переходить на v4.

Связанный контент