Добавление оснастки (скрипта) для control для управления членством доменного пользователя из freeipa в локальной группе sambashare и установки соответствующих прав на домашнюю директорию для работы общих папок. Предполагаемый формат вызова: control sambashare-membership enble|disable %username% enable: - добавляем пользователя в группу sambashare - устанавливаем права на домашнюю директорию 701 (chmod o+x) disable: - удаляем пользователя из группы sambashare - ставим права на домашнюю директорию 0700 (по умолчанию)
Собственно, вопрос в том, можно ли в таком виде аргументы давать для 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 на домашнюю директорию гостевой доступ не заработает.
