Пользователь Windows может перезаписать разрешения NFSv4/Solaris ACL для файлов на общем ресурсе CIFS/SMB (предоставить себе полный доступ), как я могу предотвратить это?
У меня настроен общий доступ к файлам SMB/CIFS на сервере OmniOS с модулем ядра Solaris, который использует списки ACL 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 для всех (или запрещение пользователям определенных разрешений на удаление), похоже, не работает в моем случае, и я не знаю почему.
2 ответа
После игнорирования этой проблемы в течение недели она теперь внезапно работает... Я не знаю, что вызвало это, но это работает... Я попробовал предложение из этого блога, но изменил его, чтобы включить AW как права. Затем я проверил это снова, на этот раз только с моими старыми правилами отказа (полностью перезаписывая новые), это также сработало. Наконец я использовал самые первые настройки из своего собственного вопроса, которые никогда не работали, но теперь они сработали.
После некоторого дополнительного тестирования, я думаю, это произошло из-за того, что служба SMB не была перезапущена раньше и ACL общего ресурса были неправильно распознаны. Изменение их было единственным способом, которым я мог восстановить старое (и неправильное) поведение.
Таким образом, для дальнейшего использования, решение состоит в том, чтобы определить нормальные разрешения для самих файлов, а не разрешить Co разрешения на уровне общего ресурса:
Примените следующие правила 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Примените следующие правила 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Перезапустите сервер 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, который проверяет "только начальная запись" или подобное.
ИМХО, все становится действительно запутанным, если вы удалите тривиальные acls для пользователя, группы, всех. Что нужно учитывать:
- В случаях отказа в разрешениях или при отсутствии разрешения на доступ к файлу подсистема привилегий определяет, какой запрос доступа предоставляется владельцу файла или суперпользователю. Этот механизм предотвращает блокировку владельцев файлов и позволяет суперпользователю изменять файлы в целях восстановления.
- Списки ACL на основе черновика POSIX используют одну запись, чтобы определить, какие разрешения разрешены, а какие запрещены. Новая модель ACL имеет два типа ACE, которые влияют на проверку доступа: ALLOW и DENY
- Владельцу файла предоставляется разрешение write_acl безоговорочно, даже если в разрешении явно отказано.
- Если вы измените права доступа к файлу, ACL файла будет обновлен соответствующим образом. Кроме того, если вы удалите нетривиальный ACL-список, который предоставил пользователю доступ к файлу или каталогу, этот пользователь все еще может иметь доступ к файлу или каталогу из-за битов разрешения файла или каталога, которые предоставляют доступ к группе или каждому
Таким образом, мой подход состоит в том, чтобы изменить тривиальные acls в соответствии с потребностями (использовать режим отказа), а затем добавить нетривиальные acls для всех особых случаев использования. Имейте это в виду также:
- После того как разрешение разрешено, оно не может быть отклонено последующей записью запрета ACL в том же наборе разрешений ACL.
Если вы не знаете, что такое OmniOS, но эти документы помогли мне понять ACL NFS. Мы используем Solaris с ZFS https://docs.oracle.com/cd/E53394_01/html/E54801/ftyxi.html