Bug 39436

Собственно, вопрос в том, можно ли в таком виде аргументы давать для control?

А что будут делать остальные операции, например, что будет показывать control sambashare-membership status?

Пока что у меня складывается впечатление, что это задача не для control.

а control вообще же не бывает per-user.

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

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

control sambashare-member@<username> enable

в этом случае и status будет возвращать и в списке можно будет выводить.

(Ответ для Dmitry V. Levin на комментарий #3)
> Пока что у меня складывается впечатление, что это задача не для control.
+1; к такому расширению API не готов и alterator-control (понятно, что он тоже
не вылит из чугуния, но у нас пока и куда более понятное/простое предложение по иерархическим объ/ектам control не нашло себе желающих сделать).

Зато вполне можно написать один-два скрипта, которые будут делать желаемое,
и уже к ним писать хоть морду, хоть ручки в системы управления конфигурацией.

Мне кажется, что в текущем виде задача поставлена некорректно. Дело тут вот в чём:
- если рассматривать, что все пользователи локальные и мы для них вводим настройки, то такой формат был хоть как-то обеспечен;
- но, даже для локальных пользователей, такой механизм выглядит сомнительно. В какой момент должна применяться такая политика?
- если речь идёт о глобальных (удалённых/сетевых/доменных), то такую настройку нужно применять? Каждый раз на каждом узле для кажого пользователя? Или во время логина всё-таки?
- кроме того, для глобальных пользователей, должен быть источник таких настроек, иначе каком смысл автоматизировать настройку, если её всё равно придётся включать вручную на каждом узле?

В связи с этим, кроме локального механизма применения той или иной политик (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 - вариант реализровать можно.

А можно я ещё немного по(пара)ною и поставлю под сомнение идею сделать chmod o+x ~user?

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

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

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

Если это нужно только для того, чтобы файловый сервер (который smbd) добрался до пошаренного каталога, то давайте, например, запускать этот файловый сервер от специального отдельного ограниченного пользователя и давать именно этому пользователю нужный +x через setfacl.

> на https://www.altlinux.org/Samba/Usershares люди и без этого что-то делают.

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

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