Назад | Перейти на главную страницу

Пользователь Windows может перезаписать разрешения NFSv4 / Solaris ACL для файлов на общем ресурсе CIFS / SMB (предоставить себе полный доступ), как мне предотвратить это?

У меня настроен общий доступ к файлам SMB / CIFS на сервере OmniOS с модулем ядра Solaris, который использует списки контроля доступа NFSv4, которые должны правильно работать с клиентами Windows.

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

Я пробовал следующий ACL, который в основном работает:

/usr/bin/chmod A=\
user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
/pool/share

Но если alice просматривает Безопасность вкладка недавно добавленных файлов в проводнике Windows, она может предоставить себе полный доступ и впоследствии удалить файл, даже если у нее нет Co прав.

Как объяснить такое поведение? И как его изменить, чтобы нельзя было изменять ACL?

Изменить: вывод ls вроде нормально:

# /usr/bin/ls -v
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    0:user:root:read_data/write_data/append_data/read_xattr/write_xattr
        /execute/delete_child/read_attributes/write_attributes/delete
        /read_acl/write_acl/write_owner/synchronize:inherited:allow
    1:user:alice:read_data/write_data/append_data/read_xattr
        /write_xattr/execute/read_attributes/write_attributes/read_acl
        /synchronize:inherited:allow

# /usr/bin/ls -V
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    user:root:rwxpdDaARWcCos:------I:allow
    user:alice:rwxp--aARWc--s:------I:allow

Выход ls для самого каталога:

# /usr/bin/ls -Vd
drwx------+  3 root     root           4 2016-03-21 .
 user:root:rwxpdDaARWcCos:fd-----:allow
user:alice:rwx---a-R-c--s:-------:allow
user:alice:rwxp--aARWc--s:f-i----:allow

# /usr/bin/ls -vd
drwx------+  3 root     root           4 2016-03-21 .
    0:user:root:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /delete_child/read_attributes/write_attributes/delete/read_acl
        /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
    1:user:alice:list_directory/read_data/add_file/write_data
        /read_xattr/execute/read_attributes/read_acl/synchronize:allow
    2:user:alice:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /read_attributes/write_attributes/read_acl/synchronize
        :file_inherit/inherit_only:allow

Файловая система общего ресурса - ZFS. Наиболее интересные свойства, отличные от значений по умолчанию, следующие:

NAME        PROPERTY        VALUE          SOURCE
pool/share  type            filesystem     -
pool/share  compression     lz4            inherited from pool
pool/share  atime           off            local
pool/share  aclmode         restricted     local
pool/share  aclinherit      passthrough    local
pool/share  version         5              -
pool/share  utf8only        on             -
pool/share  normalization   formD          -
pool/share  casesensitivity insensitive    -
pool/share  nbmand          on             local
pool/share  sharesmb        name=testshare local

Разрешения общего ресурса CIFS настроены так, чтобы предоставить всем полный доступ, поэтому должны применяться только права доступа к файлу.

Обновить:

Эта ветка очень похожа на мою проблему, хотя решение с уменьшением списков ACL в /pool/share/.zfs/shares/testshare к modify_set для всех (или отказать пользователям в определенных разрешениях на удаление), похоже, не работает в моем случае, и я не знаю, почему.

После игнорирования этой проблемы в течение недели, теперь она внезапно срабатывает ... Я не знаю, что ее вызвало, но она работает ... Я попробовал предложение от этот блог, но изменил его, чтобы включить AW как человека. Затем я снова протестировал его, на этот раз только с моими старыми правилами запрета (полностью перезаписав новые), которые также сработали. Наконец, я использовал самые первые настройки из моего собственного вопроса, которые никогда не работали, но теперь они сработали.

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

Итак, для справки в будущем решение состоит в том, чтобы определить обычные разрешения для самих файлов и не разрешать Co разрешения на уровне общего ресурса:

  1. Примените следующие правила ACL к каталогу и (унаследованные) ко всем вновь созданным файлам:

    /usr/bin/chmod A=\
user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
/pool/share

  2. Примените следующие правила ACL к скрытому общему каталогу набора данных ZFS (это необходимо, чтобы владелец не мог изменять списки ACL, подробности см. В ответе @ embedded и связанной публикации serverfault):

    /usr/bin/chmod A=\
user:root:full_set:-------:allow,\          # root has full access
everyone@:modify_set:-------:allow \        # anyone else cannot modify permissions
/pool/share/.zfs/shares/testshare

  3. Перезагрузите SMB-сервер (необходимо обновить измененные списки управления доступом к общим ресурсам, см. эта тема):

    svcadm restart svc:/network/smb/server:default # restart service
svcs -xv svc:/network/smb/server:default       # check if the startup date has changed

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

  • Вы должны запомнить / задокументировать, что вы изменили уровень общего ресурса, если в будущем должны быть установлены дополнительные разрешения.
  • Не исключено, что пользователь изменяет содержание документов. Например, alice может перезаписывать символы или строки в текстовом документе. Я думаю, это связано с тем, что приложению, которое я использую, нужны права добавления и записи, и нет ACL, который проверяет "только начальную запись" или что-то подобное.

ИМХО все становится действительно запутанным, если вы удалите тривиальные ACL для пользователя, группы, всех. Что следует учитывать:

  • В случаях отказа в разрешениях или при отсутствии разрешения на доступ к файлу подсистема привилегий определяет, какой запрос доступа предоставляется владельцу файла или суперпользователю. Этот механизм предотвращает блокировку доступа владельцев файлов к своим файлам и позволяет суперпользователю изменять файлы в целях восстановления.
  • Списки управления доступом на основе POSIX используют одну запись, чтобы определить, какие разрешения разрешены, а какие - запрещены. В новой модели ACL есть два типа ACE, которые влияют на проверку доступа: ALLOW и DENY.
  • Владельцу файла безоговорочно предоставляется разрешение write_acl, даже если разрешение явно отклонено.
  • Если вы измените права доступа к файлу, ACL файла обновится соответствующим образом. Кроме того, если вы удалите нетривиальный ACL, который предоставил пользователю доступ к файлу или каталогу, этот пользователь все еще может иметь доступ к файлу или каталогу из-за битов прав доступа к файлу или каталогу, которые предоставляют доступ группе или всем.

Итак, мой подход состоит в том, чтобы изменить тривиальные ACL в соответствии с потребностями (использовать режим запрета), а затем добавить нетривиальные ACL для всех особых случаев использования. Имейте это в виду:

  • После того, как разрешение было предоставлено, оно не может быть отклонено последующей записью запрета ACL в том же наборе разрешений ACL.

Если не знаю, что такое OmniOS, но эти документы помогли мне понять NFS ACL. Мы используем Solaris с ZFS https://docs.oracle.com/cd/E53394_01/html/E54801/ftyxi.html#scrolltoc