У нас есть FreeNAS-9.2.1.3-RELEASE-x64, предоставляющий общий ресурс samba для IIS (размещенный на 2012 R2, если это актуально)
ssasan01# smbd --version
Version 4.1.6
Сервер freenas присоединен к AD, предоставляемой серверами Windows. Домен "AD". Сайты IIS запускаются как пользователь активного каталога, уникальный для этого сайта. Идентификатор пула приложений (каждый сайт имеет свой собственный) и «учетные данные физического пути» для сайта в IIS настроены на одного и того же пользователя Active Directory.
По большей части все работает, кроме создания папки. В папке, к которой пользователь IIS имеет доступ (запись / изменение / чтение / выполнение) (на самом деле App_Data), код приложения пытается создать папку с помощью DirectoryInfo.Create. Полученная папка успешно создается на диске и, похоже, наследует Разрешения ACL от родителя, однако вызов create возвращает ошибку.
Access to the path --snip--\App_Data\packages\created\__testFolder__ is denied.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.UnauthorizedAccessException: Access to the path --snip--\App_Data\packages\created\__testFolder__ is denied.
В журнале samba log появляется следующая ошибка (уровень в настоящее время 1, так как это производственный сервер)
Sep 8 17:28:05 ssasan01 smbd[54843]: [2014/09/08 17:28:05.026127, 0] ../source3/smbd/open.c:543(change_dir_owner_to_parent)
Sep 8 17:28:05 ssasan01 smbd[54843]: change_dir_owner_to_parent: failed to change current working directory to --snip--/App_Data/packages/created/__testFolder__. Error was Permission denied
(--snip-- замена базового пути)
Файлы вроде работают правильно. Если я просматриваю созданную папку через SSH, я вижу следующее:
d-w-rwx---+ 2 AD\applicationpoolidentity group 2 Sep 8 17:28 __testFolder__
(AD \ applicationpoolidentity - это пользователь сайта, группа такая же, как и другие папки)
Та же ошибка / проблема возникает, если я пытаюсь создать папку с помощью проводника Windows, когда я вошел в систему как пользователь, имеющий доступ к общему ресурсу (и доступ для записи в рассматриваемую папку). Папка, по крайней мере, в соответствии с windows, настроена на наследование разрешений. В этом случае вновь созданная папка не получает назначенных ей списков управления доступом (у проводника нет разрешения на созданную папку), но я подозреваю, что это, скорее всего, связано с проблемой типа порядка операций, как когда IIS / .net создает папку в другом сценарии, все происходит в другом порядке, чем при создании папки через проводник.
Я просмотрел файл smb.conf вручную, чтобы устранить потенциальные проблемы с графическим интерфейсом, вот те, которые, на мой взгляд, могут иметь отношение к поиску в Google для этой проблемы. Во время тестирования я добавил «принудительный режим создания» и «принудительный режим каталога».
unix extensions = no
acl check permissions = true
acl map full control = true
create mask = 0666
directory mask = 0777
force create mode = 0666
force directory mode = 0777
inherit owner = yes
inherit permissions = yes
inherit acls = yes
writeable = yes
browseable = yes
Примечание: все папки и файлы создаются через клиент samba (а не напрямую из оболочки Linux) либо с помощью кода IIS, выполняемого от имени пользователя, имеющего права на эту папку, либо через окно проводника Windows при входе на сервер в качестве пользователя, имеющего права на создание файлов и папок. Файлы вроде работают правильно.
Мы используем здесь freenas из-за моментальных снимков ZFS плюс избыточность, он также предоставляет службы NFS для других машин и iSCSI для других машин, поэтому заменяя этот сервер файловым сервером на базе Windows (или, если на то пошло, другим сервером SAN / NAS), в то время как, не исключено, это будет нелегкая работа.
Одна возможная странность заключается в том, что владелец всех папок и файлов для всего дерева является пользователем уровня администратора (не администратором!), что позволяет нам иметь доступ и изменять разрешения в качестве администраторов.
Обновление 1: Работая с ошибкой в журнале, похоже, что папка создана успешно, но тогда у процесса самбы нет разрешения на изменение в эту папку, чтобы установить разрешения. Родительская папка (в данном случае «созданная») была настроена со следующей маской: d---rwx---+
. Если я chmod 777 created
(папка, в которой я пытаюсь создать новые папки), то процесс IIS (и проводник Windows) могут успешно создавать и удалять папки в этом подкаталоге.
Мы тестируем два разных процесса: при тестировании с помощью проводника Windows я вхожу в Windows как пользователь домена, который является «владельцем» и «группой» родительской папки. Этот же пользователь также имеет полный контроль, предоставленный через ACL. Группа имеет rwx через маску. При тестировании через .net / IIS пул работает от имени пользователя, которому через ACL предоставлены права записи / изменения / чтения (все, кроме полного контроля). Этот пользователь не является владельцем или группой, и нет разрешений по маске для всех.
Ошибка исчезнет, и все будет работать правильно, если я chmod 777
папка, которая является непосредственным родителем той, которую я пытаюсь создать. Я не думаю, что это решит проблему, поскольку это не безопасно для всего 777, особенно учитывая, что мы используем полный ACL.
Обновление 2 007 работает, 000 не работает - похоже, здесь используется бит общедоступной маски, независимо от ACL и независимо от того, какой пользователь используется для общего доступа. Это потому, что пользователь, имеющий доступ к общему ресурсу, не является владельцем или группой? Мы не хотим добавлять всех пользователей сайта в группу и давать группе возможность записи с помощью масок unix, поскольку это допускает уязвимость безопасности обхода пути (тогда один пользователь сайта будет иметь доступ ко всем другим папкам сайта, поскольку они являются участниками группы), не так ли? Мы могли бы выборочно применить "owner" '700' и исключить корни сайта и их дочерние элементы для пользователя сайта, но это кажется довольно недостижимым и обходит использование ACL и наследования? Или 007/777 в этом случае безопасен из-за использования ACL в качестве другого уровня?
Обновление 3 Проверил исходный код samba для open.c, чтобы узнать, что на самом деле делает change_dir_owner_to_parent. Сначала он получает папку с помощью getwd (кэшируется согласно getwd_cache), а затем выполняет cwd в эту папку, чтобы «заблокировать» ее, чтобы смена владельца не находилась в состоянии гонки. Вот где мои тесты, кажется, терпят неудачу. В предыдущих тестах / обновлениях я обнаружил, что если я даю xx7 чему-либо, то он работает и продолжает работать даже после того, как я снова сниму маску всех. Я предполагаю, что это кеширование проверок разрешений, поэтому проблема возникнет снова, когда срок действия кеша истечет / станет недействительным. Я не уверен, какая переменная кеша применима к этому. Я нашел папку, которая не работала (было 070), и подтвердил, что не могу правильно создавать новые папки. Затем я использовал chmod для предоставления 074 папке и подтвердил, что это решило проблему. Так что это лучше, чем 777, но все еще не уверены, зачем это вообще нужно? Мне нужно chmod -R 074 * для всей доли?
Обновление 4 Обнаружена другая папка, которая была сломана (было 070) - подтверждена с помощью пользовательского интерфейса CMS и создана папка, подтверждающая, что процесс, который создает папку, не работает. Затем применил chmod 000 к родительскому через SSH. Теперь процесс успешно создает папку. Что происходит?! Я не касался списков ACL Windows ни для одного из этих тестов.
Обновление 5 Закончились сломанные папки для тестирования ... взял папку, которая была 070 и не работала (проверено в CMS), а затем chmod 070 ее (те же разрешения, что и в настоящее время), и теперь я могу создавать элементы внутри папки через CMS (с использованием списков ACL Windows, которые предоставляют разрешения) Итак, если я изменю сломанную папку на что-нибудь, то она начнет работать?
Это потому что это
d-w-rwx---+ 2 AD\applicationpoolidentity group 2 Sep 8 17:28 __testFolder__
представляет ТОЛЬКО владелец. Вы видите "+" в конце битовой маски? Это означает, что есть (windows) acl, контролирующий доступ. Поэтому, если у вас есть доступ к файлу, потому что вы находитесь в acl с r / w, битовая маска владельца не применима к вам (если вы не ЯВЛЯЮТСЯ владелец). Если вы явно не в acl, 007 работает, потому что это означает, что «любой, кроме пользователя-владельца и кроме группы владельцев, имеет доступ к файлу».
В более ранних версиях FreeNAS можно было исследовать ACL с помощью «ls -v». К сожалению, это больше не работает. Я не понял, как это сейчас можно исследовать со стороны Unix.
HTH