IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Now that we make the user/group name resolving available via userdb and
thus nss-systemd, we do not need the UID/GID resolving support in
nss-mymachines anymore. Let's drop it hence.
We keep the module around, since besides UID/GID resolving it also does
hostname resolving, which we care about. (One of those days we should
replace that by some Varlink logic between
nss-resolve/systemd-resolved.service too)
The hooks are kept in the NSS module, but they do not resolve anything
anymore, in order to keep compat at a maximum.
This changes nss-systemd to use the new varlink user/group APIs for
looking up everything.
(This also changes the factory /etc/nsswitch.conf line to use for
hooking up nss-system to use glibc's [SUCCESS=merge] feature so that we
can properly merge group membership lists).
Fixes: #12492
Booting up an image with --volatile=yes otherwise looks so naked, so
let's include this file in the default factory too. It's common and
simple and should be safe to ship.
Apparently PAM reacts differently on different systems (?) and if no
authoritative matching module is found might either succeed/fail,
depending on the system.
Let's lock this down explicitly, by hooking in pam_deny.so.
Of course, these PAM files are just examples, and no distro in its right
mind would ship these unmodified, but let's default to something safe.
Fixes: #12950
Stupid PAM, please just go away!
login[26]: pam_limits(login:session): error parsing the configuration file: '/etc/security/limits.conf'
login[26]: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
login[26]: Error in service module
