[Devel] noperm и монтирование samba

Сб Янв 17 02:10:46 MSK 2009

16 января 2009 г. 22:32 пользователь Vitaly Lipatov <lav на etersoft.ru> написал:
> В сообщении от 16 января 2009 Evgeny Sinelnikov написал(a):
> ...
>> > Как сервер проверяет права, если пользователи с разными UID на локальной
>> > машине будут обращаться к одной точке монтирования?
>> на основании uid'а пользователя на сервере, на который мапится
>> вошедший пользователь... Для force user = User  - работа ведётся
> Откуда взялась идея, что uid мапится на что-то другое? У нас по умолчанию
> включен LinuxExtensions, и uid соответствует на сервере и клиенте. Разве при
> LinuxExtensions может быть проблема с несоответствием? Или я недопонял?

Идея маппинга относится не к маппингу uid'a на что-то, а имени - на
uid, и не к клиентской части, где включены или выключены
LinuxExtensions, а к samba-серверу. Если я обращаюсь на самбу под
пользователем guest, то я в системе, на самбе, аутентифицируюсь тем
пользователем на кого этот guest маппиться... Обычно это nobody, хотя
где как настроено, по умолчанию...

Так вот далее, войдя под пользователм guest, я пройду или не пройду
аутентификацию и получу или не получу права на запись на уровне шары
(это я назвал первым уровнем)... Допустим, что получу.... Но, чтобы
иметь возможность писать в этой шаре... У пользователя nobody должны
быть права на запись в каталог, куда эта шара определена (это я назвал
вторым уровнем)...

Пример:
[shara]
   path = /var/ftp
   guest ok = yes

так вот, если у пользователя nobody не будет прав писать в каталог
/var/ftp, то и записать он туда не сможет...

Далее возьмём клиента:
смонтируем каталог из под анонимного пользователя, который будт
замаплен на nobody
$ cifsmount //base/shara shara
Password:
[sin на base ~]$ ls -l shara/
итого 16
drwxr-sr-x  18 sin  ftpadmin     0 Сен 17 22:42 ALTLinux
drwxr-x---  18 sin  ftpadmin     0 Авг  4 02:53 Backup
-rw-r--r--   1 sin  sin      15866 Сен 18  2007 COPYING
drwxrws---   4 sin  users        0 Янв 20  2008 Documents
drwxr-sr-x   9 sin  ftpadmin     0 Сен 29 14:39 Etersoft
drwxrwxr-x  47 sin  ftpadmin     0 Янв 11 03:51 library
drwxrwsr-x  15 root ftpadmin     0 Янв 27  2008 Local
drwx------   2 root root         0 Июн 23  2007 lost+found
drwxr-sr-x   2 root ftpadmin     0 Июн 26  2007 Maps
drwxr-sr-x   5 sin  ftpadmin     0 Окт 26 18:16 old
drwxrwsr-x+  9 sin  ftpadmin     0 Окт 17 10:32 Photo
drwxr-sr-x   7 sin  ftpadmin     0 Авг 29  2007 Projects
drwxr-xr-x   3 root root         0 Апр 28  2008 pub
lrwxrwxrwx   1 sin  ftpadmin     4 Авг  9  2007 srv -> /srv
drwxr-sr-x   5 sin  ftpadmin     0 Авг 10  2007 System
drwxr-sr-x   2 sin  ftpadmin     0 Окт 19 21:18 tmp
drwxr-sr-x   3 sin  ftpadmin     0 Дек 26  2007 tst
drwxr-sr-x   8 sin  ftpadmin     0 Янв  8 00:54 Work
drwxr-sr-x   2 sin  ftpadmin     0 Апр 27  2008 Папка
[sin на base ~]$ ls -ld shara/
drwxr-xr-x 20 root root 0 Окт 26 18:16 shara/
[sin на base ~]$ mkdir shara/tdt
mkdir: невозможно создать каталог `shara/tdt': Отказано в доступе
[sin на base ~]$ touch shara/tmp/tetst
touch: невозможно выполнить touch для `shara/tmp/tetst': Отказано в доступе

Досадно... не прописывать же везде nobody... А хотелось бы анонимный
доступ без пароля...
Ну, что ж... Сделаем-ка force user = sin... Тогда всё действительно
будет работать...

Но у клиента есть ещё один уровень проверки - локальный на уровне
cifs. Назовём его нулевой... Если sin на другом хосте будет иметь
другой uid, то подмонтированная шара покажет не локальное имя sin, а а
то имя которое будет соответсвовать uid'у с сервера... и клиент будет
думать, что писать право не имеет ещё до попытки отправки команды на
сервер... Таким образом это нулевой уровень не будет соответствовать
реальности... Писать можно, а клиент думает, что нельзя...

Как быть? Отключить нулевой уровень проверок и предоставить серверу
самому решать можно или нельзя... Для этого используется параметр
монтирования noperm. Похожего преследуют и попыткой вручную задать
опции uid=sin,gid=users,file_mode=0644.

Но есть разница, поскольку noperm честно не пытается себя
ограничивать, отдавая запросы серверу... А вариант uid,gid,file_mode
пытается обмануть самого себя... Иногда удачно, иногда - нет...
Последнее, вероятно, ещё и некорректно...

>
>
>> именно под этим пользователем... Если force user не установлен, то
>> работа ведётся из под того, под кем залогинились... его uid
> Да, сам процесс smbd для шары под ним запускается.
>
>> используется при вычислении прав на файловой системе сервера поверх
>> тех прав, которые прописаны в настройках шары.
>>
>> То есть ограничения двухуровневые:
>> - на уровне доступа к шаре
>> - на уровне доступа к файлам на файловой системе для вошедшего
>> пользователя...
>>
>> именно поэтому не удобно давать без force user шару в хомячке, ибо
>> тогда нужно права на запуск в домашний каталог давать всем, либо всех,
> Что за шара в хомячке?

Ну, вот захотел я расшарить по самбе для всех без разбора каталог
/home/sin/Documents/Photo
А у меня:
$ ls -ld /home/sin/
drwxr-x--- 201 sin sin 20480 Янв 17 01:31 /home/sin/

И если не задать для это шары force user, что в общем-то логично, то
произвольный guest доступа к ней, даже на просмотр каталога, не
получится.

> Я правильно понимаю, что одной точкой монтирования невозможно
> подключить /home, содержащий каталоги разных пользователей, с тем, чтобы на
> локальной машине они все могли работать в своих каталогах?
>

Это вполне возможно, но для этого uid/gid должны совпадать на всех
машинах, и хаками uid=user,gid=group,file_mode=0XYZ или noperm
пользоваться уже нельзя.... всё должно проходить в чистую... клиент
должен видеть ФС именно так, как её видит сервер, чтобы не возникала
коллизий.

>> >> Если синхронизации по uid, gid нет (и по тому в какие группы входит
>> >> пользователь тоже, то есть по всей авторизационной информации), то
>> >> клиент не может правильно рассчитать права. Получается ситуация, что
>> >
>> > Допустим, она есть. При этом проблемы не будет?
>>
>> Да, синхронизация даст много плюсов... Эта часть в первую очередь
>> отличает Tartarus от AD... У AD есть ряд костылей, но в целом
>> однозначно мапить sid'ы всё равно не удастся... Самый прямой путь -
>> держать соответствие в LDAP, а для этого схему расширять нужно, чна
>> что не все готовы пойти....
> Эта идея о использовании CIFS совместно с Tartarus появилась вчера, или она
> уже может быть сформулирована на wiki?
>

Эта идея заключается в необходимости интеграции cifs с kerberos на
уровне проброса ключей из userspace и предполагалась всегда... Вопрос
в том, чтобы научить самбу аутентифицировать через kerberos не только
для AD, но и для Tartarus. Это ключевой вопрос и решать его иначе, чем
патчами для сабы пока не ясно как... Разве, что воспользоваться
механизмами бекендов для Samba4...

>> >> некоторые действия, разрешены на сервере, но CIFS-модуль считает, что
>> >> они запрещены и выдает permission denied, а некоторые считает, что
>> >> разрешены, а сервер выдает запрет. Сервер контролирует права в любом
>> >
>> > А почему в наших экспериментах ошибка зависит от интервала между
>> > операциями?
>>
>> Я думаю, что это бага CIFS при использовании uid'ов... На самом деле
>> всё должно работать... такое ощущение, что сразу после создания
>> каталога uid=user некорректно отдаёт реальный uid, вместо
>> подставного....

-- 
Sin (Sinelnikov Evgeny)