ALT Linux Community general discussions
 help / color / mirror / Atom feed
From: Evgeny Sinelnikov <sin@altlinux.org>
To: ALT Linux Community general discussions <community@lists.altlinux.org>
Cc: Andrey Cherepanov <cas@altlinux.org>
Subject: Re: [Comm] Создание пользователей в Альтераторе
Date: Tue, 19 Oct 2021 02:21:07 +0400
Message-ID: <CAK42-Goi9Zgx+0PQTy9QXCfuOi2TF5fNuRkUvtfwawOZaRREdw@mail.gmail.com> (raw)
In-Reply-To: <246391634570731@mail.yandex.ru>

Доброй ночи.

пн, 18 окт. 2021 г. в 23:59, Максим Калинин <maxkalinin@yandex.ru>:
>
> + boyarsh@, community@
>
> Да нет необходимости в  "Контроллере Домена" в качестве отдельной сущности ..
> Нужен единственный файловый сервер с авторизацией, на котором домашние каталоги.
> И пользователей два десятка.
> Просто с доменом это делается достаточно быстро и просто ..
>
> Можно это (автосоздание каталогов) где-то подкрутить ?
> Или тянуть p7 ?

Конечно, можно. Давайте разберемся в некоторых деталях.

Модуль pam_mkhomedir используется для создания домашних каталогов для
вновь созданных пользователей при их логине на конкретную машину.
Он отрабатывает через цепочку модулей для заданных приложений в
каталоге /etc/pam.d

На текущий момент все механизмы аутентификации разделены на
специфические для конкретной задачи модули. В частности system-auth
отделён от system-policy:

$ sudo control system-auth help
krb5: authentication via Kerberos 5
krb5_ccreds: authentication via Kerberos 5 with local caching
ldap: authentication via LDAP
local: local authentication
multi: use multi authentication method
pkcs11: use pkcs11 authentication method
pkcs11_strict: use pkcs11_strict authentication method
sss: use sss authentication method
winbind: authentication via Winbind

$ sudo control system-policy help
gpupdate: use gpupdate session policy
local: local session policy
remote: remote session policy with mkhomedir

Кроме того, system-auth отрабатывает соответствующие модули сетевой
аутентификации только для нелокальных пользователей (то есть таких
пользователей, имена которых отсутствуют в /etc/passwd) по следующей
схеме:

MODULE        [success=4 perm_denied=ignore default=die]    pam_localuser.so
MODULE        [success=1 default=bad]    pam_succeed_if.so uid >= 500 quiet
MODULE        [default=1]    pam_permit.so
MODULE        substack    system-auth-sss-only
MODULE        [default=1]    pam_permit.so
MODULE        substack    system-auth-local-only
MODULE        substack    system-auth-common

Список всех возможных вариантов можно посмотреть в соответствующих
файлах настройки, которые управляются через control system-auth:
$ ls -1 /etc/pam.d/system-auth-* | grep -v -e '.*-only$' -e
'.*-use_first_pass.*' -e 'system-auth-common'
/etc/pam.d/system-auth-krb5
/etc/pam.d/system-auth-krb5_ccreds
/etc/pam.d/system-auth-ldap
/etc/pam.d/system-auth-local
/etc/pam.d/system-auth-multi
/etc/pam.d/system-auth-pkcs11
/etc/pam.d/system-auth-pkcs11_strict
/etc/pam.d/system-auth-sss
/etc/pam.d/system-auth-winbind

Модуль pam_mkhomedir перенесён в механизм, управляемый через
соответствующий control system-policy (см. help выше). Этот механизм
применяется только для приложений выполняющих вход в систему
(common-login), что исключает сайд-эффекты "ложного" срабатывания для
локальных подсистем. Например, для системных сервисов.

# cat /etc/pam.d/common-login
#%PAM-1.0
auth        substack    system-auth
auth        substack    system-policy
auth        required    pam_nologin.so
account        substack    system-auth
account        substack    system-policy
account        required    pam_nologin.so
password    include        system-auth
password    include        system-policy
session        substack    system-auth
session        required    pam_loginuid.so
-session    optional    pam_systemd.so
session        substack    system-policy

_____________________________

Насколько я понимаю, чтобы вернуть "оригинальное" поведение, которое
ожидается для данного случая, достаточно вписать модуль pam_mkhomedir
в файл system-auth-common:

# cat /etc/pam.d/system-auth-common
#%PAM-1.0
#account        required    pam_access.so
session        required    pam_mktemp.so
session        required    pam_limits.so

Примерно так:

#%PAM-1.0
#account        required    pam_access.so
session        required    pam_mkhomedir.so silent
session        required    pam_mktemp.so
session        required    pam_limits.so

Не думаю, что это правильный путь, но он должен решить вашу проблему.

_____________________________

Правильно же было бы разобраться со схемой управления пользователями в
ALT-домене и добавить в него соответствующий функционал по созданию
каталогов.

Честно говоря, я не очень понимаю сценарий работы всей этой схемы.
Предполагаю, что домен, как бы всё-таки есть. Или нет? Есть там же и
файловый сервер. И вот получается, что файловый сервер не пускает
пользователей, поскольку домашние каталоги для них не создаются. Но
кто бы сказал, что они должны создаваться? Наверное, для этого нужна
соответствующая "ручка".

Правильно ли я понимаю, что создавая учётную запись ALT-домене,
предполагается, что на этом же сервере разворачивается файловый
Samba-сервер и на этом же сервере у всех пользователей домена
создаются домашние каталоги?

Подозреваю, что оригинальный сценарий реализован в модуле
alterator-ldap-users в функции ldap_user_new(), примерно следующим
образом:
 513     # trying to init user homedir
 514     local init_user="$(su - $1 -s /bin/true > /dev/null 2>&1)"

То есть это изначально, особенный вариант поведения под конкретную
задачу. Вот именно "su - USERNAME" больше и не отрабатывает. Да и не
должен. Тут нужно придумать что-то более надёжное и предсказуемое.
Думаю, стоит добавить для этой задачи явную галочку - создавать
домашний каталог пользователя. Но где его нужно создавать? На каком
сервере? Ведь вовсе не обязательно, что файловый сервер и сервер
ALT-домена будут на одном узле.

По уму, данное поведение не имеет никакого отношения к созданию
пользователей. Насколько я понимаю, требуется, чтобы при первой
попытке захода на файловую шару создавался домашний каталог
пользователя. Скорее всего, этот каталог даже не требуется
инициализировать файлами из /etc/skel. Более того, даже не стоит,
наверное, располагать домашние каталоги в /home. Надёжнее было бы
перенести шару [homes] в отдельный каталог, например, /people или
/srv/home. Для создания же пустых домашних каталогов стоит
воспользоваться скриптами. Для этого существует специальная опция exec
или preexec (см. man smb.conf):
https://serverfault.com/questions/576136/how-to-force-samba-to-create-directory

Предлагаю повесить по этому поводу багу на alterator-ldap-users с
конкретным предложением по данному поведению. Хотя к
alterator-ldap-users эта проблема не имеет никакого отношения. Тут
нужно галочку в управлялке файловым сервером делать.

_____________________________

Ещё раз. Вернуть оригинальное поведение просто (см. детали выше) -
достаточно вписать модуль pam_mkhomedir в
/etc/pam.d/system-auth-common.

Но это стоит проверить. Буду благодарен, если кто-нибудь подтвердит,
что всё так и есть.


>
>
> Спасибо!
>
> 16.10.2021, 12:21, "Andrey Cherepanov" <cas@altlinux.org>:
>
> А какая разница, какой тип домена? Зачем на контроллере домена создавать домашние каталоги всех доменных пользователей?
>
> 15.10.2021 22:23, Максим Калинин пишет:
>
> Так ведь домен-то "ALT-Domain", а не ActiveDirectory !
> Для него не нужен отдельный контроллер и отдельный файловый сервер, достаточно одного ...
> В таком варианте очень не удобно сначала в Альтераторе создавать юзера, затем вручную создавать ему каталог с соответствующими правами ...!
>
> Логично ?
>
>
>
> 15.10.2021, 21:20, "Andrey Cherepanov" <cas@altlinux.org>:
>
> 15.10.2021 17:06, Максим Калинин пишет:
>
>  Здравствуйте!
>  С удивлением обнаружил, что на вновь поставленном Alt Server 9 ( при
>  созданном AT-домене )
>  при создании пользователя в Альтераторе его домашний каталог не создается.
>  Создается только для локальных Unix-пользователей ...
>  Такая же ситуация с Alt Server 8.2.1 ..
>  В дистрибутивах на основе p7 подобного поведения не наблюдалось.
>  Или, может быть, я делаю что-то не так ?
>
> А с чего должны создаваться домашние каталоги доменных пользователей на
> сервере? Обычно домашние каталоги пользователей создаются на вводимых в
> домен ПК. Так что логично и оправдано.
>
>
> --
> Andrey Cherepanov
> cas@altlinux.org
>
>
>
>
> --
> С уважением,
> Калинин Максим
>
>
>
>
>
> --
> Andrey Cherepanov
> cas@altlinux.org
>
>
>
> --
> С уважением,
> Калинин Максим
>
>
> _______________________________________________
> community mailing list
> community@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/community



-- 
Sin (Sinelnikov Evgeny)

  parent reply	other threads:[~2021-10-18 22:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-18  8:39 ` Anton V. Boyarshinov
2021-10-18 22:21         ` Evgeny Sinelnikov [this message]
2021-10-19  7:49         ` Anton V. Boyarshinov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK42-Goi9Zgx+0PQTy9QXCfuOi2TF5fNuRkUvtfwawOZaRREdw@mail.gmail.com \
    --to=sin@altlinux.org \
    --cc=cas@altlinux.org \
    --cc=community@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Community general discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 community community/ http://lore.altlinux.org/community \
		mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com
	public-inbox-index community

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.community


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git