Bug#883347: systemd fails to load pam_unix.so when spawning user.service

Michael Biebl biebl at debian.org
Sat Dec 2 21:43:46 GMT 2017


Am 02.12.2017 um 22:39 schrieb Michael Biebl:
> Hi Russ!
> 
> Am 02.12.2017 um 19:41 schrieb Russ Allbery:
>> Package: systemd
>> Version: 235-3
>> Severity: normal
>>
>> Since upgrading a system to 235-3, all ssh connections are producing the
>> following syslog errors:
>>
>> Dec  2 06:28:23 lothlorien systemd: PAM unable to dlopen(pam_unix.so): /lib/security/pam_unix.so: cannot open shared object file: No such file or directory
>> Dec  2 06:28:23 lothlorien systemd: PAM adding faulty module: pam_unix.so
>> Dec  2 06:28:23 lothlorien sshd[20758]: pam_systemd(sshd:session): Failed to create session: Start job for unit user at 999.service failed with 'failed'
>> Dec  2 06:28:23 lothlorien systemd[20760]: PAM failed: Authentication failure
>> Dec  2 06:28:23 lothlorien systemd[20760]: user at 999.service: Failed to set up PAM session: Operation not permitted
>> Dec  2 06:28:23 lothlorien systemd[20760]: user at 999.service: Failed at step PAM spawning /lib/systemd/systemd: Operation not permitted
>> Dec  2 06:28:23 lothlorien systemd[1]: user at 999.service: Failed with result 'protocol'.
>> Dec  2 06:28:23 lothlorien systemd[1]: Failed to start User Manager for UID 999.
>>
>> I'm fairly confused by this, and I'm not sure whether to blame systemd or
>> libpam or some other component.  Obviously, the problem is that for some
>> reason it's trying to load /lib/security/pam_unix.so instead of the correct
>> multiarch path of /lib/x86_64-linux-gnu/security/pam_unix.so (which does
>> exist), but I have no idea why on earth it's doing that, or why this would
>> have changed with the upgrade.
>>
>> The ssh connection does successfully continue, but I suspect that's because
>> I'm not relying on anything provided by the user session at the moment.
>>
>> Everything else about PAM on this system is working fine; only systemd's
>> user.service seems to be having problems.
> 
> systemd-logind.service was locked down further in v235. A diff of
> systemd-logind.service shows:
> 
> +LockPersonality=yes
> +IPAddressDeny=any
> 
> 
> I'm not entirely sure if that is related, but you might try commenting
> those two lines out in /lib/systemd/system/systemd-logind.service and
> see if that makes a difference.

AppArmor was enabled just recently. It might be worth a try to disable
any LSM if active.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20171202/4dd4f0d5/attachment-0002.sig>


More information about the Pkg-systemd-maintainers mailing list