Bug 39436 - добавление функционала управления членством в samba usershares для доменных пользователей
Summary: добавление функционала управления членством в samba usershares для доменных п...
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: control (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P5 enhancement
Assignee: Dmitry V. Levin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-14 12:18 MSK by Danil Shein
Modified: 2020-12-16 15:00 MSK (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Danil Shein 2020-12-14 12:18:07 MSK
Добавление оснастки (скрипта) для control для управления членством доменного пользователя из freeipa в локальной группе sambashare и установки соответствующих прав на домашнюю директорию для работы общих папок.

Предполагаемый формат вызова:
control sambashare-membership enble|disable %username%

enable:
  - добавляем пользователя в группу sambashare
  - устанавливаем права на домашнюю директорию 701 (chmod o+x)

disable:
  - удаляем пользователя из группы sambashare
  - ставим права на домашнюю директорию 0700 (по умолчанию)
Comment 1 Sergey V Turchin 2020-12-14 12:38:38 MSK
Собственно, вопрос в том, можно ли в таком виде аргументы давать для control?
Comment 2 Dmitry V. Levin 2020-12-14 12:42:51 MSK
А что будут делать остальные операции, например, что будет показывать control sambashare-membership status?
Comment 3 Dmitry V. Levin 2020-12-14 12:44:22 MSK
Пока что у меня складывается впечатление, что это задача не для control.
Comment 4 Anton Farygin 2020-12-14 13:27:48 MSK
а control вообще же не бывает per-user.

Т.е. - это скорее запрос на такую фичу, как per-user control.

если и делать в control. то синтаксис может быть таким же как в systemd:

control sambashare-member@<username> enable

в этом случае и status будет возвращать и в списке можно будет выводить.
Comment 5 Michael Shigorin 2020-12-15 14:50:08 MSK
(Ответ для Dmitry V. Levin на комментарий #3)
> Пока что у меня складывается впечатление, что это задача не для control.
+1; к такому расширению API не готов и alterator-control (понятно, что он тоже
не вылит из чугуния, но у нас пока и куда более понятное/простое предложение по иерархическим объ/ектам control не нашло себе желающих сделать).

Зато вполне можно написать один-два скрипта, которые будут делать желаемое,
и уже к ним писать хоть морду, хоть ручки в системы управления конфигурацией.
Comment 6 Evgeny Sinelnikov 2020-12-16 05:03:16 MSK
Мне кажется, что в текущем виде задача поставлена некорректно. Дело тут вот в чём:
- если рассматривать, что все пользователи локальные и мы для них вводим настройки, то такой формат был хоть как-то обеспечен;
- но, даже для локальных пользователей, такой механизм выглядит сомнительно. В какой момент должна применяться такая политика?
- если речь идёт о глобальных (удалённых/сетевых/доменных), то такую настройку нужно применять? Каждый раз на каждом узле для кажого пользователя? Или во время логина всё-таки?
- кроме того, для глобальных пользователей, должен быть источник таких настроек, иначе каком смысл автоматизировать настройку, если её всё равно придётся включать вручную на каждом узле?

В связи с этим, кроме локального механизма применения той или иной политик (control per user или какой-то другой) необходимо рассмотреть два ключевых вопроса:
- источник настроек для глобальных пользователей (а также, возможно, локальных, но это нужно отдельно вписывать в планируемые требования к разрабатываемому решению);
- сценарий применения такого механизма (во время логина или как-то ещё), включающий в себя дополнительный механизм получения информации о настройках конкретного пользователя.

Ещё раз подчеркну, для глобальных пользователей, которые ещё не логинились на конкретном узле, раскидывать настройки на каждый такой узел не имеет никакого смысла. Это так не масштабируется.

_________________

Данная задача полностью соответствует механизму применения групповых политик gpupdate, который уже первично разработан и интегрирован во все дистрибутивы старше 9.1. Предлагаю рассмотреть возможности применения этого механизма в данной задаче.

Несмотря на то, что gpupdate разработан под реализацию применения политик Active Directory (AD), мы его специально разрабатывали под возможность реализации различных бекендов.

На текущий момент у нас предусмотрено два бекенда - локальный и samba-бекенд. На текущий момент локальный бекенд используется для бутстрапной настройки политик через профили-шаблоны в пакете local-policy. Следующий шаг в разработке предполагает включение полноценной локальной политики, которая, в первую очередь, планировалась как локальная политика безопасности.

Получаем три слоя политик:
- профиль дистрибутива (сервер, рабочая станция, контроллер домена, кастомный вариант), который в read only устанавливается из пакета;
- локальная политика безопасности поверх профиля задаёт конкретные локальные настройки узла и управляется через разрабатываемый нами графический инструмент gpgui;
- набор глобальных политик из LDAP-базы, который выкачивается в AD из сетевого каталога sysvol и назначается для заданного подразделения (для вложенных подразделений в дереве объектов может получится несколько политик), также дополнительно для сайта (подсеть, по сути), отдельного пользователя или компьютера (см. https://habr.com/ru/post/327648/).

Таким образом вопрос не в том, чтобы задать для каждого пользвателя на данном компьютере настройку группа + права на домашний каталог. Если же рассматривать именно такой вариант настройки, но она совершенно не нужна в per user варианте.

В таком, упрощённом виде - это политика компьютера включающая в себя два пункта:

- Разрешать пользователям создавать пользовательские общие каталоги на файловом samba-сервере для этого ничего не нужно - всё уже разработано, достаточно выполнить:
# roleadd ipausers sambashare
или шире - для всех пользователей
# roleadd users sambashare 
# roleadd ipausers users

- Разрешать всем пользователя на данном компьютере общие каталоги на файловом samba-сервере из своего домашнего каталога.

Второй пункт здесь крайне спорный:
- Почему права 701, а не 711. Потому что речь идёт о глобальных пользователях, которые входят в одну и ту же группу? 
- Как быть с ранее логинившимися пользователями?
- В какой момент должен вызываться предлагаемый control?

Я считаю, что вопрос задания прав на домашний каталог - не задача данной политики. Права на каталог должен задавать тот инструмент (или пользователь в консоли), который будет содавать файл настройки в usershare-каталоге, путь к которому указывается в smb.conf.

_____

Для запуска настроек во время логина уже разработан pam-oddjob-gpupdate. В целом, если пока уйти от вопроса об источнике настроек, то если добавить локальный источник, о котором я писал выше, то per user - вариант реализровать можно.
Comment 7 Ivan A. Melnikov 2020-12-16 14:11:14 MSK
А можно я ещё немного по(пара)ною и поставлю под сомнение идею сделать chmod o+x ~user?

Во-первых, это штука не обязательная -- на https://www.altlinux.org/Samba/Usershares люди и без этого что-то делают.

Во-вторых, это штука слишком не специфичная -- у меня могут быть и другие причины возвести этот бит или убрать его.

В-третьих, это имхо слишком большая дыра -- я уже побежал делать chmod 700 ~/Documents, а вы?

Если это нужно только для того, чтобы файловый сервер (который smbd) добрался до пошаренного каталога, то давайте, например, запускать этот файловый сервер от специального отдельного ограниченного пользователя и давать именно этому пользователю нужный +x через setfacl.
Comment 8 Danil Shein 2020-12-16 15:00:49 MSK
> на https://www.altlinux.org/Samba/Usershares люди и без этого что-то делают.

Там без chmod o+x на домашнюю директорию будет работать только вариант с размещением расшариваемой папки в другом месте (не в домашней директории) и установки на неё соответствующих прав.

Если создавать общую папку через плагин файлового менеджера в домашней директории, то без установки прав o+x на домашнюю директорию гостевой доступ не заработает.