Как работают “cifsacl” или “idsfromsid” с “modefromsid” в CIFS/SMB? Как я могу использовать их для поддержки прав Unix на сервере Samba?

У меня есть сервер Samba на FreeBSD и ZFS и клиент Linux, которому нужно смонтировать общую папку Samba. Чтобы избежать проблем с совместимостью, она должна быть смонтирована так, чтобы соблюдались и поддерживались права Unix на стороне клиента. Согласно моему исследованию, при монтировании общей папки Samba с помощью драйвера CIFS для Linux есть 5 возможных способов обработки прав Unix:

1. Монтирование через uid=,gid=,dir_mode=,file_mode=.

   Права Unix не поддерживаются в базовом протоколе CIFS/SMB, их нельзя использовать на обычном сервере SMB без каких-либо расширений. Следовательно, указание этих параметров заставит драйвер CIFS для Linux использовать стандартных владельцев, группы и режимы для всех файлов, и их нельзя изменить.

2. Включение расширения Unix для SMBv1 через unix extensions = yes на Samba

   В прошлом HP определила расширение Unix для SMBv1. Когда используется расширение Unix для SMBv1, информация о владельце, группе и режиме автоматически передается от сервера к драйверу CIFS клиента Linux. Пока UID и GID совпадают на сервере и клиенте, это должно вести себя как локальная файловая система Unix.

   К сожалению, SMBv1 небезопасен и был отменен много лет назад, что делает этот вариант неприемлемым. Возможно, его все еще можно использовать в пределах частной VPN, но я действительно не хочу использовать этот устаревший вариант.

3. Включение расширения POSIX для SMBv3 через smb3 unix extensions = yes, монтирование через posix

   Недавно были проведены работы по разработке нового расширения POSIX для SMBv3, которое позволяет использовать права Unix и другие функции. К сожалению, хотя опция posix уже была добавлена в драйвер CIFS для Linux, поддержка Samba остается экспериментальной и требует сборки для разработки, поэтому ее нельзя использовать в производственных системах.

4. Отображение прав ACL через cifsacl, принудительно на сервере.

5. Отображение прав в стиле NFS через idsfromsid, modefromsid, принудительно на клиенте.

Согласно различным презентациям разработчиков с 2020 года, драйвер CIFS для Linux поддерживает варианты 4 и 5 для включения прав Unix через отображение из ACL или SID, управляемое параметрами монтирования cifsacl, idsfromsid и modefromsid. Утверждается, что эти функции готовы к использованию в производстве. Некоторые посты также упоминали, что cifsacl принудительно на сервере и часто используется вместе с idmap, в то время как idsfromsid и modefromsid используют модель разрешений, принудительно применяемую клиентом в стиле NFS, которая является более простой опцией для общего доступа для одного пользователя.

К сожалению, похоже, что почти нет документации для cifsacl, idsfromsid и modefromsid, хотя эти функции были разработаны 4 года назад. Есть только несколько упоминаний об этих опциях из презентаций на конференциях разработчиков, но общественностью о них известно очень мало. Например, официальная документация kernel.org имеет только загадочное заявление, но без какого-либо объяснения о том, как правильно их использовать:

Рекомендации: для повышения безопасности диалект SMB2.1 или более поздний (обычно будет SMB3.1.1) теперь является новым по умолчанию. […] Есть дополнительные параметры монтирования, которые могут быть полезны для SMB3, чтобы получить улучшенное поведение POSIX (Примечание: можно использовать vers=3 для принуждения к SMB3 или более позднему, никогда 2.1): mfsymlinks и либо cifsacl, либо modefromsid (обычно с idsfromsid)

Когда я попробовал добавить idsfromsid и modefromsid в параметры монтирования, это, похоже, не сработало. Если команда mount выполняется от имени root, все файлы внутри точки монтирования все равно принадлежать root, а не фактическому пользователю на сервере. Режимы для этих файлов нельзя изменить, даже от имени root. Поведение кажется идентичным обычному CIFS/SMB без каких-либо расширений.

Вопрос

1. Как работает cifsacl в CIFS/SMB?
2. Как работают idsfromsid и modefromsid в CIFS/SMB?
3. Как правильно их использовать? Меня особенно интересует использование метода idsfromsid и modefromsid, так как он выглядит проще.

Библиография

1. Руководство пользователя и администратора ядра Linux » CIFS » Использование

2. SMB3.1.1 POSIX/расширения Linux – Стивен Френч

3. Расширения протокола SMB3.1.1 POSIX: Резюме и текущее состояние реализации

4. Доступ Linux к облаку и NAS воскрес: Недавний прогресс в SMB3.1.1

5. Будущее удаленного доступа к файлам из Linux: обновление SMB3.1.1

6. Поддерживаемые параметры монтирования CIFS

7. [Samba] Как включить расширения POSIX для SMB3 на сервере Samba?

Читая исходный код ядра Linux, мне кажется, я решил одну часть головоломки.

Как работают idsfromsid и modefromsid в CIFS/SMB?

В SMB у каждого пользователя или группы есть свой собственный SID, который используется для контроля доступа. Эти пользователи управляются инструментами Samba, такими как pdbedit или smbpasswd. Это отличается от аккаунтов Unix, управляемых инструментами Unix, такими как passwd или useradd.

С помощью Samba можно просмотреть ACL файла или каталога через:

$ smbcacls //server/share /dir -U user

Например, следующая команда перечисляет ACL корневого каталога //server/share. ACL Samba хранятся как ACL файловой системы Unix (черновик POSIX ACL или NFSv4 ACL) подлежащей файловой системе, которая может не иметь смысл под Unix. Но всегда есть три специальных записи ACL для Пользователя, Группы и Всех, которые соответствуют правам Unix.

$ smbcacls //server/share / -U user
Пароль для [WORKGROUP\user]:
REVISION:1
CONTROL:SR|DP
OWNER:SERVER\user
GROUP:Unix Group\user
ACL:SERVER\user:ALLOWED/0x0/0x001e01ff
ACL:Unix Group\user:ALLOWED/0x0/READ
ACL:Everyone:ALLOWED/0x0/READ

В выводе OWNER:SERVER\user означает, что владельцем файла является пользователь Samba, а GROUP:Unix Group\user означает, что группой файла является группа Unix. Почему есть разница?

Когда пользователь Unix имеет соответствующий аккаунт Samba, сервер Samba автоматически сопоставляет аккаунт Unix с этим аккаунтом Samba. Но когда пользователь или группа неизвестны Samba, специальные SID используются как заполнители для несопоставленных аккаунтов Unix.

Это можно наглядно показать, проверив сырые SID в числовом формате:

$ smbcacls //server/share / -U user --numeric
Пароль для [WORKGROUP\user]:
REVISION:1
CONTROL:0x8004
OWNER:S-1-5-21-3329942186-90701280-2335022555-1001
GROUP:S-1-22-2-1002
ACL:S-1-5-21-3329942186-90701280-2335022555-1001:0/0x0/0x001e01ff
ACL:S-1-22-2-1002:0/0x0/0x001200a9
ACL:S-1-1-0:0/0x0/0x001200a9

Обратите внимание, что Owner является реальным SID S-1-5-21-3329942186-90701280-2335022555-1001, 1001 соответствует ID пользователя Samba в pdbedit -L -v. Но Group имеет специальный заполнитель SID S-1-22-2-1002, 1002 соответствует действительному ID группы Unix.

В другом примере давайте рассмотрим файл, контролируемый пользователем и группой Unix, о которых Samba ничего не знает:

# smbcacls //server/share / -U user --numeric
Пароль для [WORKGROUP\user]:
REVISION:1
CONTROL:0x8004
OWNER:S-1-22-1-1009
GROUP:S-1-22-2-1010
ACL:S-1-22-1-1009:0/0x0/0x001e01ff
ACL:S-1-22-2-1010:0/0x0/0x001200a9
ACL:S-1-1-0:0/0x0/0x001200a9

Таким образом, становится очевидным, что:

1. SID S-1-22-1-uid является зарезервированным SID Samba для представления несопоставленного пользователя Unix.

2. SID S-1-22-2-gid является зарезервированным SID Samba для представления несопоставленной группы Unix.

Это именно то, как работает idsfromsid. Согласно исходному коду Linux, когда idsfromsid установлен, драйвер CIFS сопоставит все файлы на удаленном сервере с SID S-1-22-1-uid и S-1-22-1-gid с локальным пользователем Unix с тем же uid и gid. Также распознаются другие конвенции, изначально использовавшиеся Windows: S-1-5-88-1-uid / S-1-5-88-2-gid.

/* См. http://technet.microsoft.com/en-us/library/hh509017(v=ws.10).aspx */
static void setup_owner_group_sids(char *buf)
{
    struct owner_group_sids *sids = (struct owner_group_sids *)buf;

    /* Заполните поля владельца пользователей S-1-5-88-1 */
    sids->owner.Revision = 1;
    sids->owner.NumAuth = 3;
    sids->owner.Authority[5] = 5;
    sids->owner.SubAuthorities[0] = cpu_to_le32(88);
    sids->owner.SubAuthorities[1] = cpu_to_le32(1);
    sids->owner.SubAuthorities[2] = cpu_to_le32(current_fsuid().val);

    /* Заполните поля группы-владельца S-1-5-88-2 */
    sids->group.Revision = 1;
    sids->group.NumAuth = 3;
    sids->group.Authority[5] = 5;
    sids->group.SubAuthorities[0] = cpu_to_le32(88);
    sids->group.SubAuthorities[1] = cpu_to_le32(2);
    sids->group.SubAuthorities[2] = cpu_to_le32(current_fsgid().val);
}

Кроме того, согласно исходному коду ядра Linux, modefromsid работает аналогично. Он использует зарезервированный SID S-1-5-88-3-mode для записи прав Unix. Эта запись ACL читается и переводится в права Unix клиентом CIFS для Linux, и она также обновляется, когда права Unix файла изменяются.

Способ обхода

Когда я попробовал добавить idsfromsid и modefromsid в мои параметры монтирования, это, похоже, не сработало. Если команда монтирования выполняется от имени root, все файлы внутри точки монтирования все равно принадлежат root, а не фактическому пользователю на сервере. Режимы для этих файлов нельзя изменить, даже от имени root. Поведение кажется идентичным обычному CIFS/SMB без каких-либо расширений.

После того как я узнал теорию работы idsfromsid, я также нашел корень проблемы. Проблема возникает, если сервер Samba знает об аккаунте Unix. В этом случае реальные SID Samba, а не заполнители, будут получать разрешения в ACL (ручное изменение владельца на зарезервированный SID через smbcacls не кажется работающим, поскольку он все равно сопоставляется обратно с реальным SID Samba). В этом случае ядро Linux не может сопоставить SID как локальный аккаунт Unix, и idsfromsid не срабатывает.

Это можно подтвердить, включив отладку на клиенте CIFS:

# echo "module cifs +p" > /sys/kernel/debug/dynamic_debug/control 
# echo "module cifs/* +p" > /sys/kernel/debug/dynamic_debug/control 
# echo 7 > /proc/fs/cifs/cifsFYI 
# dmesg | grep cifsacl
CIFS: fs/smb/client/cifsacl.c: sid_to_id: Не удается сопоставить SID os:S-1-5-21-3329942186-90701280-2335022555-1002 с uid
CIFS: fs/smb/client/cifsacl.c: Unix UID 1009, возвращенный от SID

Таким образом, после того как я узнал о теории работы, я нашел один способ использования idsfromsid с помощью следующего хакерского метода:

1. Создайте пользователя Samba user.
2. Измените разрешения файловой системы общей директории на несвязанный пользователь и группу Unix, о которых Samba ничего не знает, например unixuser, unixgroup.
3. Используйте force user unixuser и force group unixgroup в smb.conf, чтобы все файлы, создаваемые в этой общей директории, оставались принадлежать unixuser и unixgroup (вам также могут понадобиться дополнительные разрешения на уровне файловой системы для предоставления доступа к unixuser и unixgroup).
4. Создайте тех же unixuser и unixgroup на клиенте CIFS для Linux, вручную измените UID и GID, чтобы они соответствовали серверу Samba.
5. Смонтируйте общую папку с помощью учетной записи Samba user, с опцией idsfromsid, затем используйте файл внутри нее как unixuser (на клиенте). Теперь все владельцы файлов и группы должны автоматически сопоставляться правильно.