Bug#679928: systemd: PAM adding faulty module: pam_systemd.so

[Teodor]

Package: systemd
Version: PAM adding faulty module: pam_systemd.so
Severity: normal

After packages removal I get these on syslog:
| Jul 2 15:05:01 frost CRON[7633]: PAM unable to dlopen(pam_systemd.so):
| /lib/security/pam_systemd.so: cannot open shared object file: No such
| file or directory
| Jul 2 15:05:01 frost CRON[7633]: PAM adding faulty module: pam_systemd.so

This is probably from this line in /etc/pam.d/common-session:
| session optional pam_systemd.so

Cheers


-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii dpkg 1.16.6
ii initscripts 2.88dsf-28
ii libacl1 2.2.51-8
ii libaudit0 1:1.7.18-1.1
ii libc6 2.13-34
ii libcap2 1:2.22-1.1
ii libcryptsetup4 2:1.4.3-2
ii libdbus-1-3 1.6.2-1
ii libkmod2 9-1
ii liblzma5 5.1.1alpha+20120614-1
ii libpam0g 1.1.3-7.1
ii libselinux1 2.1.9-5
ii libsystemd-daemon0 44-3
pn libsystemd-id128-0 <none>
pn libsystemd-journal0 <none>
ii libsystemd-login0 44-3
ii libudev0 175-3.1
ii libwrap0 7.6.q-23
ii udev 175-3.1
ii util-linux 2.20.1-5.1

Versions of packages systemd recommends:
pn libpam-systemd <none>

Versions of packages systemd suggests:
ii python 2.7.3-1
ii python-cairo 1.8.8-1+b2
ii python-dbus 1.1.1-1
pn systemd-gui <none>

[Tollef Fog Heen]

]] Teodor

Post by Teodor
Package: systemd
Version: PAM adding faulty module: pam_systemd.so
Severity: normal
| /lib/security/pam_systemd.so: cannot open shared object file: No such
| file or directory
| Jul 2 15:05:01 frost CRON[7633]: PAM adding faulty module: pam_systemd.so
| session optional pam_systemd.so

I suspect you have told pam that you want to manage common-session by
hand, else this is a bug in pam-auth-update, since the postinst just
says:

if [ "$1" = "remove" ] ; then
pam-auth-update --package --remove systemd
fi

Can you please verify?

[Michael Biebl]

Post by Tollef Fog Heen
]] Teodor

Post by Teodor
Package: systemd
Version: PAM adding faulty module: pam_systemd.so
Severity: normal
| /lib/security/pam_systemd.so: cannot open shared object file: No such
| file or directory
| Jul 2 15:05:01 frost CRON[7633]: PAM adding faulty module: pam_systemd.so
| session optional pam_systemd.so

I suspect you have told pam that you want to manage common-session by
hand, else this is a bug in pam-auth-update, since the postinst just
if [ "$1" = "remove" ] ; then
pam-auth-update --package --remove systemd
fi

Right, the issue is, that we switched to multiarch paths in 44-3.

I think pam-auth-update should handle that correctly, i.e. update the
paths in the pam configuration even if the pam-configs snippet hasn't
changed.

Steve, can you confirm that this should work?

Is there an easy way to check if the pam configuration is managed
manually and not by pam-auth-update?


Michael

[Steve Langasek]

Post by Michael Biebl

Post by Tollef Fog Heen

Post by Teodor
| session optional pam_systemd.so

I suspect you have told pam that you want to manage common-session by
hand, else this is a bug in pam-auth-update, since the postinst just
if [ "$1" = "remove" ] ; then
pam-auth-update --package --remove systemd
fi

Right, the issue is, that we switched to multiarch paths in 44-3.

What does this have to do with multiarch paths? The module path shouldn't
have been embedded in the pam-auth-update profile anyway - was it?

Post by Michael Biebl
I think pam-auth-update should handle that correctly, i.e. update the
paths in the pam configuration even if the pam-configs snippet hasn't
changed.

There should be *no* paths in the configuration, therefore there should be
nothing to update. You should use unqualified module names and trust pam's
internal path - which AFAICS is what is done here.

Post by Michael Biebl
Steve, can you confirm that this should work?
Is there an easy way to check if the pam configuration is managed
manually and not by pam-auth-update?

I believe this is stored in debconf as libpam-runtime/override.

[Michael Biebl]

Post by Steve Langasek

Post by Michael Biebl
Right, the issue is, that we switched to multiarch paths in 44-3.

What does this have to do with multiarch paths? The module path shouldn't
have been embedded in the pam-auth-update profile anyway - was it?

[..]

Post by Steve Langasek
There should be *no* paths in the configuration, therefore there should be
nothing to update. You should use unqualified module names and trust pam's
internal path - which AFAICS is what is done here.

Yeah, I'm really sorry for all the noise.
The issue is most certainly not about multiarch paths.

What seems to be the problem here is that Teodor has libpam-systemd no
longer installed but there is still a corresponding line in common-session.

As Tollef already mentioned, this should only happen if Teodor chose to
manage common-session by hand. Otherwise
pam-auth-update --package --remove systemd
would have removed it. (assuming there isn't a bug in pam-auth-update)

Teodor, could you attach the output of "debconf-show libpam-runtime" please.
Do you remember editing /etc/pam.d/common-session by hand?

Michael

[Tollef Fog Heen]

]] Michael Biebl

Post by Michael Biebl
What seems to be the problem here is that Teodor has libpam-systemd no
longer installed but there is still a corresponding line in common-session.

I think what might have happened is an aborted upgrade, which I don't
think we currently handle correctly. I'll have to take a look at the
code in question, though.

[Teodor MICU]

Post by Tollef Fog Heen
I think what might have happened is an aborted upgrade, which I don't
think we currently handle correctly. I'll have to take a look at the
code in question, though.

My guess is that this problem was caused by a deadlock in the upgrade.
The packages were upgraded and started to execute the post-install
configuration. But one of these packages (clamav-freshclam) has failed
to configure (due to missing init-functions script) and the process
was aborted, thus systemd packages didn't get configured either.

To conclude, I see two problems to get fixed:
- make sure as early as possible on package install/upgrade that the
diversion is removed (probably pre-inst)
- make sure on package removal that the diversion is removed (probably pre-rm).

Cheers

[Michael Biebl]

Post by Teodor MICU

Post by Tollef Fog Heen
I think what might have happened is an aborted upgrade, which I don't
think we currently handle correctly. I'll have to take a look at the
code in question, though.

I think we handle the pam-auth-update bits as suggested by the pam
documentation.
We run pam-auth-update --package in postinst, at that point the package
should be fully installed/unpacked.

I'm still unsure about the sequence of events that happened that led to
this situation. Especially in what state the libpam-systemd package was in.


Or were you talking about the removal of the lsb hook diversion?

Post by Teodor MICU
My guess is that this problem was caused by a deadlock in the upgrade.
The packages were upgraded and started to execute the post-install
configuration. But one of these packages (clamav-freshclam) has failed
to configure (due to missing init-functions script) and the process
was aborted, thus systemd packages didn't get configured either.
- make sure as early as possible on package install/upgrade that the
diversion is removed (probably pre-inst)
- make sure on package removal that the diversion is removed (probably pre-rm).

The /lib/lsb/init-scripts diversion is gone and has been replaced by the
/lib/lsb/init-functions.d/40-systemd snippet.
So all problems regarding diversions should be fixed.
Unless there is a problem how we handle the removal of the old diversion
in systemd.preinst? But this looks fine to me.

That said, if there is a problem wrt /lib/lsb/init-functions, then this
is a different issue, even if those two issues might be related.



Michael

[Teodor MICU]

Post by Michael Biebl
Teodor, could you attach the output of "debconf-show libpam-runtime" please.
Do you remember editing /etc/pam.d/common-session by hand?

No, I don't think that's the case as showed in a previous message were
a manual execution works properly. The issue is probably that the code
was not executed.

***@frost:~# debconf-show libpam-runtime
libpam-runtime/override: false
libpam-runtime/conflicts:
libpam-runtime/no_profiles_chosen:
libpam-runtime/profiles: unix, winbind, gnome-keyring, consolekit
libpam-runtime/you-had-no-auth:
libpam-runtime/title:

Cheers

[Teodor MICU]

Post by Tollef Fog Heen
I suspect you have told pam that you want to manage common-session by
hand, else this is a bug in pam-auth-update, since the postinst just
if [ "$1" = "remove" ] ; then
pam-auth-update --package --remove systemd
fi
Can you please verify?

I don't think this is the case. Executing that command manually works just fine:

--- pam.d/common-session 2012-07-03 10:33:23.000000000 +0300
+++ /etc/pam.d/common-session 2012-07-03 11:11:34.438015939 +0300
@@ -23,7 +23,6 @@
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session optional pam_winbind.so
-session optional pam_systemd.so
session optional pam_ck_connector.so nox11
# end of pam-auth-update config

The problem might be that the above script was not executed on
removal? (ie. postrm or something)

Cheers

[Michael Biebl]

Post by Teodor MICU

Post by Tollef Fog Heen
if [ "$1" = "remove" ] ; then
pam-auth-update --package --remove systemd
fi
Can you please verify?

[..]

Post by Teodor MICU
The problem might be that the above script was not executed on
removal? (ie. postrm or something)

It is called in prerm, which means it's called on removal.

So far this problem is unfortunately not reproducible here.

Tollef, the only issue I see is that libpam-systemd is missing a
dependency on libpam-runtime (>= 1.0.1-6), which we should add in any case.

That said, it is most unlikely though that Teodor did not have
libpam-runtime installed when he removed libpam-systemd (as this would
have generated a failure due to the missing pam-auth-update).

If "pam-auth-update --package --remove systemd" did not trigger a
warning about locally modified configuration, I'm a bit at a loss here
what could have caused the problem for Teodor.