[RFC] pam_unix: use helper on skeleton root entry from libnss-systemd #484
Conversation
libnss-systemd started[1] to synthesize a root entry with an invalid
password. On Debian since version 251.3-2[2] systemd enables the
systemd module for shadow and gsshadow in nsswitch.conf. This leads on
SELinux enabled systems, where the files module can not access the
shadow file, to the root account being locked.
Fall back to the unix_chkpwd helper in case the root user was queried
and the response was a locked password ("!*"[3]).
[1]: systemd/systemd@f43a19ecd6e3415e
[2]: https://salsa.debian.org/systemd-team/systemd/-/commit/bf9a307cfcbe62ab4fbcf2198e6e628a1bca211b
[3]: https://github.com/systemd/systemd/blob/b622e95f2f59fcb58e23ddafed745eee26a0f52f/src/nss-systemd/nss-systemd.c#L34
|
Since both the module and its helper use the same |
|
In the helper linux-pam/modules/pam_unix/passverify.c Line 41 in 510e825 |
|
And both are essentially the same thing, so is there any observable difference? |
The helper is allowed to read /etc/shadow (by SELinux), while the pam module caller is probably not, thus the first module |
|
If that's the case, I'd suggest to change the module to use the helper unconditionally without even trying to use |
|
Wouldn't that defeat the whole purpose of nss? An alternative would be to change |
What would defeat the whole purpose of nss is a special handling of things like libnss-systemd in a generic code. |
|
It's true, the added workaround specific for libnss-systemd is a bit messy, but circumventing nss entirely (e.g. ldap module) might break setups. |
If SELinux is enabled and pam_unix calls directly the helper application, why should that circumvent nss entirely and might break setups? |
…file entries Initially, when pam_unix.so verified the password, it used to try to obtain the shadow password file entry for the given user by invoking getspnam(3), and only when that didn't work and the effective uid was nonzero, pam_unix.so used to invoke the helper as a fallback. When SELinux support was introduced by commit 67aab1f, the fallback was extended also for the case when SELinux was enabled. Later, commit f220cac extended the fallback conditions for the case when pam_modutil_getspnam() failed with EACCES. Since commit 470823c, the helper is invoked as a fallback when pam_modutil_getspnam() fails for any reason. The ultimate solution for the case when pam_unix.so does not have permissions to obtain the shadow password file entry is to stop trying to use pam_modutil_getspnam() and to invoke the helper instead. Here are two recent examples. #484 describes a system configuration where libnss_systemd is enabled along with libnss_files in the shadow entry of nsswitch.conf, so when libnss_files is unable to obtain the shadow password file entry for the root user, e.g. when SELinux is enabled, NSS falls back to libnss_systemd which returns a synthesized shadow password file entry for the root user, which in turn locks the root user out. https://bugzilla.redhat.com/show_bug.cgi?id=2150155 describes essentially the same problem in a similar system configuration. This commit is the final step in the direction of addressing the issue: for password verification pam_unix.so now invokes the helper instead of making the pam_modutil_getspnam() call. * modules/pam_unix/passverify.c (get_account_info) [!HELPER_COMPILE]: Always return PAM_UNIX_RUN_HELPER instead of trying to obtain the shadow password file entry. Complements: #386 Resolves: #484 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2150155
libnss-systemd started1 to synthesize a root entry with an invalid
password. On Debian since version 251.3-22 systemd enables the
systemd module for shadow and gsshadow in nsswitch.conf. This leads on
SELinux enabled systems, where the files module can not access the
shadow file, to the root account being locked.
Fall back to the unix_chkpwd helper in case the root user was queried
and the response was a locked password ("!*"3).
See also systemd/systemd#20299 for previous issue leading to 470823c.