[Bug 2060676] Re: [SRU] login: remove pam_lastlog.so from config
Tim Andersson
2060676 at bugs.launchpad.net
Mon Nov 18 12:55:21 UTC 2024
Looking for sponsorship for this!
** Description changed:
[ Impact ]
* The following line has been found in users logs when trying to log in to their systems:
login[2449]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory
This is the only known occurrence of the log. It occurs when users log in to their systems using a tty, or rather referred to as the 'login' method in shadow/pam etc. This log error message is not present when logging in via ssh, gdm, xdm, or other login methods, as they do not depend on the lastlog binary.
* The upload fixes the issue by dropping pam_lastlog.so from all
config, as well as not installing the lastlog binary.
[ Test Plan ]
```
wget https://releases.ubuntu.com/noble/ubuntu-24.04.1-desktop-amd64.iso
qemu-system-x86_64 -boot d -cdrom /path/to/ubuntu-24.04.1-desktop-amd64.iso -m 8192M -smp 2 -hda /tmp/yarf-vm.qcow2 -enable-kvm -device qxl
# install the system, and reboot
# at the login screen post-reboot, press ctrl+alt+f2
# login via tty
journalctl -b 0 --no-pager | grep pam_lastlog.so
# and you will see the error message
sudo sed '/session optional pam_lastlog.so/d' /etc/pam.d/login
# logout
# log back in via tty
journalctl # check the logs since you logged in, you will not see any mention of pam_lastlog.so
```
* In order to test this after the fix lands in noble proposed, do the
same as above, except instead of manuall removing the entry from
/etc/pam.d/login, install the version of shadow from proposed, and
assert that the log messages are no longer present.
[ Where problems could occur ]
- * Any production systems that use lastlog in a `required` manner may be
- broken by this change, if they are not already in a broken state. This
- SRU doesn't remove the lastlog binary, just the requirement for tty
- login. I believe the impact would be minimal.
+ * Users may have installed a custom or manually compiled lastlog binary
+ and be relying on the default pam config to use it. This would be an
+ obscure edge case, however. I can't imagine anyone would configure
+ login.pam to explicitly *require* pam_lastlog.so, I also can't imagine
+ anyone would create any functionality that'd explicitly *depend* on
+ pam_lastlog.so being *required*.
[ Other Info ]
* the pam_lastlog.so binary was dropped in shadow/1:4.13+dfsg1-5.
Included in this change also is dropping pam_lastlog.so from
debian/login.pam.
* The version of shadow in oracular is 1:4.15.3-3ubuntu2, and thus this
error message isn't present in oracular onwards.
- * We absolutely *cannot* re-introduce pam_lastlog.so as it was dropped
+ * We absolutely *cannot* re-introduce pam_lastlog.so as it was dropped
as part of the time_t transition, see commit: https://github.com/linux-
pam/linux-pam/commit/357a4ddbe9b4b10ebd805d2af3e32f3ead5b8816
* pam_lastlog2 is depended upon in util-linux after version 2.40-7. We
can make changes in shadow going forward that depends on pam_lastlog2
rather than pam_lastlog. But that's not really relevant to the SRU I
guess. These changes are planned to be implemented upstream
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=1068229;msg=39,
so likely from Ubuntu's side, we can just wait for the changes.
* However, upstream, shadow still doesn't have any mention of lastlog2
in debian/login.pam. So we can't SRU a change to depend on this new
lastlog binary, as it's not in devel yet.
* We could, however, SRU a change wherein we revert the dropping of
pam_lastlog.so in shadow, but this is more involved and would likely be
a separate SRU, wherein either that SRU or this one lands.
[Original description]
Imported from Debian bug http://bugs.debian.org/1068229:
Package: libpam-modules
Version: 1.5.3-6
Severity: normal
I noticed the following line in my logs:
login[2449]: PAM unable to dlopen(pam_lastlog.so):
/usr/lib/security/pam_lastlog.so: cannot open shared object file: No
such file or directory
I looked in the deb files from snapshot.debian.org, and noticed the last version
that had it was 1.5.2-9.1 - starting from 1.5.3-1 it disappeared.
Maybe it's fallout from the time_t transition and you're already aware of it, in
which case feel free to close.
Thanks,
-- M
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libpam-modules depends on:
ii debconf [debconf-2.0] 1.5.86
ii libaudit1 1:3.1.2-2.1
ii libc6 2.37-15.1
ii libcrypt1 1:4.4.36-4
ii libpam-modules-bin 1.5.3-6
ii libpam0g 1.5.3-6
ii libselinux1 3.5-2
ii libsystemd0 255.4-1+b1
libpam-modules recommends no packages.
libpam-modules suggests no packages.
-- debconf information excluded
** Description changed:
[ Impact ]
* The following line has been found in users logs when trying to log in to their systems:
login[2449]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory
This is the only known occurrence of the log. It occurs when users log in to their systems using a tty, or rather referred to as the 'login' method in shadow/pam etc. This log error message is not present when logging in via ssh, gdm, xdm, or other login methods, as they do not depend on the lastlog binary.
* The upload fixes the issue by dropping pam_lastlog.so from all
config, as well as not installing the lastlog binary.
[ Test Plan ]
```
wget https://releases.ubuntu.com/noble/ubuntu-24.04.1-desktop-amd64.iso
qemu-system-x86_64 -boot d -cdrom /path/to/ubuntu-24.04.1-desktop-amd64.iso -m 8192M -smp 2 -hda /tmp/yarf-vm.qcow2 -enable-kvm -device qxl
# install the system, and reboot
# at the login screen post-reboot, press ctrl+alt+f2
# login via tty
journalctl -b 0 --no-pager | grep pam_lastlog.so
# and you will see the error message
sudo sed '/session optional pam_lastlog.so/d' /etc/pam.d/login
# logout
# log back in via tty
journalctl # check the logs since you logged in, you will not see any mention of pam_lastlog.so
```
* In order to test this after the fix lands in noble proposed, do the
same as above, except instead of manuall removing the entry from
/etc/pam.d/login, install the version of shadow from proposed, and
assert that the log messages are no longer present.
[ Where problems could occur ]
* Users may have installed a custom or manually compiled lastlog binary
and be relying on the default pam config to use it. This would be an
- obscure edge case, however. I can't imagine anyone would configure
- login.pam to explicitly *require* pam_lastlog.so, I also can't imagine
- anyone would create any functionality that'd explicitly *depend* on
- pam_lastlog.so being *required*.
+ obscure edge case, however. It seems extremely improbable anyone would
+ configure login.pam to explicitly *require* pam_lastlog.so, I also can't
+ imagine anyone would create any functionality that'd explicitly *depend*
+ on pam_lastlog.so being *required*.
[ Other Info ]
* the pam_lastlog.so binary was dropped in shadow/1:4.13+dfsg1-5.
Included in this change also is dropping pam_lastlog.so from
debian/login.pam.
* The version of shadow in oracular is 1:4.15.3-3ubuntu2, and thus this
error message isn't present in oracular onwards.
* We absolutely *cannot* re-introduce pam_lastlog.so as it was dropped
as part of the time_t transition, see commit: https://github.com/linux-
pam/linux-pam/commit/357a4ddbe9b4b10ebd805d2af3e32f3ead5b8816
* pam_lastlog2 is depended upon in util-linux after version 2.40-7. We
can make changes in shadow going forward that depends on pam_lastlog2
rather than pam_lastlog. But that's not really relevant to the SRU I
guess. These changes are planned to be implemented upstream
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=1068229;msg=39,
so likely from Ubuntu's side, we can just wait for the changes.
* However, upstream, shadow still doesn't have any mention of lastlog2
in debian/login.pam. So we can't SRU a change to depend on this new
lastlog binary, as it's not in devel yet.
* We could, however, SRU a change wherein we revert the dropping of
pam_lastlog.so in shadow, but this is more involved and would likely be
a separate SRU, wherein either that SRU or this one lands.
[Original description]
Imported from Debian bug http://bugs.debian.org/1068229:
Package: libpam-modules
Version: 1.5.3-6
Severity: normal
I noticed the following line in my logs:
login[2449]: PAM unable to dlopen(pam_lastlog.so):
/usr/lib/security/pam_lastlog.so: cannot open shared object file: No
such file or directory
I looked in the deb files from snapshot.debian.org, and noticed the last version
that had it was 1.5.2-9.1 - starting from 1.5.3-1 it disappeared.
Maybe it's fallout from the time_t transition and you're already aware of it, in
which case feel free to close.
Thanks,
-- M
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libpam-modules depends on:
ii debconf [debconf-2.0] 1.5.86
ii libaudit1 1:3.1.2-2.1
ii libc6 2.37-15.1
ii libcrypt1 1:4.4.36-4
ii libpam-modules-bin 1.5.3-6
ii libpam0g 1.5.3-6
ii libselinux1 3.5-2
ii libsystemd0 255.4-1+b1
libpam-modules recommends no packages.
libpam-modules suggests no packages.
-- debconf information excluded
** Description changed:
[ Impact ]
* The following line has been found in users logs when trying to log in to their systems:
login[2449]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory
This is the only known occurrence of the log. It occurs when users log in to their systems using a tty, or rather referred to as the 'login' method in shadow/pam etc. This log error message is not present when logging in via ssh, gdm, xdm, or other login methods, as they do not depend on the lastlog binary.
* The upload fixes the issue by dropping pam_lastlog.so from all
config, as well as not installing the lastlog binary.
[ Test Plan ]
```
wget https://releases.ubuntu.com/noble/ubuntu-24.04.1-desktop-amd64.iso
qemu-system-x86_64 -boot d -cdrom /path/to/ubuntu-24.04.1-desktop-amd64.iso -m 8192M -smp 2 -hda /tmp/yarf-vm.qcow2 -enable-kvm -device qxl
# install the system, and reboot
# at the login screen post-reboot, press ctrl+alt+f2
# login via tty
journalctl -b 0 --no-pager | grep pam_lastlog.so
# and you will see the error message
sudo sed '/session optional pam_lastlog.so/d' /etc/pam.d/login
# logout
# log back in via tty
journalctl # check the logs since you logged in, you will not see any mention of pam_lastlog.so
```
* In order to test this after the fix lands in noble proposed, do the
same as above, except instead of manuall removing the entry from
/etc/pam.d/login, install the version of shadow from proposed, and
assert that the log messages are no longer present.
[ Where problems could occur ]
- * Users may have installed a custom or manually compiled lastlog binary
- and be relying on the default pam config to use it. This would be an
- obscure edge case, however. It seems extremely improbable anyone would
- configure login.pam to explicitly *require* pam_lastlog.so, I also can't
- imagine anyone would create any functionality that'd explicitly *depend*
- on pam_lastlog.so being *required*.
+ * It seems extremely improbable anyone would configure login.pam to
+ explicitly *require* pam_lastlog.so, I also can't imagine anyone would
+ create any functionality that'd explicitly *depend* on pam_lastlog.so
+ being *required*.
[ Other Info ]
* the pam_lastlog.so binary was dropped in shadow/1:4.13+dfsg1-5.
Included in this change also is dropping pam_lastlog.so from
debian/login.pam.
* The version of shadow in oracular is 1:4.15.3-3ubuntu2, and thus this
error message isn't present in oracular onwards.
* We absolutely *cannot* re-introduce pam_lastlog.so as it was dropped
as part of the time_t transition, see commit: https://github.com/linux-
pam/linux-pam/commit/357a4ddbe9b4b10ebd805d2af3e32f3ead5b8816
* pam_lastlog2 is depended upon in util-linux after version 2.40-7. We
can make changes in shadow going forward that depends on pam_lastlog2
rather than pam_lastlog. But that's not really relevant to the SRU I
guess. These changes are planned to be implemented upstream
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=1068229;msg=39,
so likely from Ubuntu's side, we can just wait for the changes.
* However, upstream, shadow still doesn't have any mention of lastlog2
in debian/login.pam. So we can't SRU a change to depend on this new
lastlog binary, as it's not in devel yet.
* We could, however, SRU a change wherein we revert the dropping of
pam_lastlog.so in shadow, but this is more involved and would likely be
a separate SRU, wherein either that SRU or this one lands.
[Original description]
Imported from Debian bug http://bugs.debian.org/1068229:
Package: libpam-modules
Version: 1.5.3-6
Severity: normal
I noticed the following line in my logs:
login[2449]: PAM unable to dlopen(pam_lastlog.so):
/usr/lib/security/pam_lastlog.so: cannot open shared object file: No
such file or directory
I looked in the deb files from snapshot.debian.org, and noticed the last version
that had it was 1.5.2-9.1 - starting from 1.5.3-1 it disappeared.
Maybe it's fallout from the time_t transition and you're already aware of it, in
which case feel free to close.
Thanks,
-- M
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libpam-modules depends on:
ii debconf [debconf-2.0] 1.5.86
ii libaudit1 1:3.1.2-2.1
ii libc6 2.37-15.1
ii libcrypt1 1:4.4.36-4
ii libpam-modules-bin 1.5.3-6
ii libpam0g 1.5.3-6
ii libselinux1 3.5-2
ii libsystemd0 255.4-1+b1
libpam-modules recommends no packages.
libpam-modules suggests no packages.
-- debconf information excluded
--
You received this bug notification because you are a member of Ubuntu
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2060676
Title:
[SRU] login: remove pam_lastlog.so from config
Status in shadow package in Ubuntu:
Fix Released
Status in shadow source package in Noble:
In Progress
Status in shadow source package in Oracular:
Fix Released
Status in shadow package in Debian:
Fix Released
Bug description:
[ Impact ]
* The following line has been found in users logs when trying to log in to their systems:
login[2449]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory
This is the only known occurrence of the log. It occurs when users log in to their systems using a tty, or rather referred to as the 'login' method in shadow/pam etc. This log error message is not present when logging in via ssh, gdm, xdm, or other login methods, as they do not depend on the lastlog binary.
* The upload fixes the issue by dropping pam_lastlog.so from all
config, as well as not installing the lastlog binary.
[ Test Plan ]
```
wget https://releases.ubuntu.com/noble/ubuntu-24.04.1-desktop-amd64.iso
qemu-system-x86_64 -boot d -cdrom /path/to/ubuntu-24.04.1-desktop-amd64.iso -m 8192M -smp 2 -hda /tmp/yarf-vm.qcow2 -enable-kvm -device qxl
# install the system, and reboot
# at the login screen post-reboot, press ctrl+alt+f2
# login via tty
journalctl -b 0 --no-pager | grep pam_lastlog.so
# and you will see the error message
sudo sed '/session optional pam_lastlog.so/d' /etc/pam.d/login
# logout
# log back in via tty
journalctl # check the logs since you logged in, you will not see any mention of pam_lastlog.so
```
* In order to test this after the fix lands in noble proposed, do the
same as above, except instead of manuall removing the entry from
/etc/pam.d/login, install the version of shadow from proposed, and
assert that the log messages are no longer present.
[ Where problems could occur ]
* It seems extremely improbable anyone would configure login.pam to
explicitly *require* pam_lastlog.so, I also can't imagine anyone would
create any functionality that'd explicitly *depend* on pam_lastlog.so
being *required*.
[ Other Info ]
* the pam_lastlog.so binary was dropped in shadow/1:4.13+dfsg1-5.
Included in this change also is dropping pam_lastlog.so from
debian/login.pam.
* The version of shadow in oracular is 1:4.15.3-3ubuntu2, and thus
this error message isn't present in oracular onwards.
* We absolutely *cannot* re-introduce pam_lastlog.so as it was
dropped as part of the time_t transition, see commit:
https://github.com/linux-pam/linux-
pam/commit/357a4ddbe9b4b10ebd805d2af3e32f3ead5b8816
* pam_lastlog2 is depended upon in util-linux after version 2.40-7.
We can make changes in shadow going forward that depends on
pam_lastlog2 rather than pam_lastlog. But that's not really relevant
to the SRU I guess. These changes are planned to be implemented
upstream https://bugs.debian.org/cgi-
bin/bugreport.cgi?att=0;bug=1068229;msg=39, so likely from Ubuntu's
side, we can just wait for the changes.
* However, upstream, shadow still doesn't have any mention of
lastlog2 in debian/login.pam. So we can't SRU a change to depend on
this new lastlog binary, as it's not in devel yet.
* We could, however, SRU a change wherein we revert the dropping of
pam_lastlog.so in shadow, but this is more involved and would likely
be a separate SRU, wherein either that SRU or this one lands.
[Original description]
Imported from Debian bug http://bugs.debian.org/1068229:
Package: libpam-modules
Version: 1.5.3-6
Severity: normal
I noticed the following line in my logs:
login[2449]: PAM unable to dlopen(pam_lastlog.so):
/usr/lib/security/pam_lastlog.so: cannot open shared object file: No
such file or directory
I looked in the deb files from snapshot.debian.org, and noticed the last version
that had it was 1.5.2-9.1 - starting from 1.5.3-1 it disappeared.
Maybe it's fallout from the time_t transition and you're already aware of it, in
which case feel free to close.
Thanks,
-- M
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libpam-modules depends on:
ii debconf [debconf-2.0] 1.5.86
ii libaudit1 1:3.1.2-2.1
ii libc6 2.37-15.1
ii libcrypt1 1:4.4.36-4
ii libpam-modules-bin 1.5.3-6
ii libpam0g 1.5.3-6
ii libselinux1 3.5-2
ii libsystemd0 255.4-1+b1
libpam-modules recommends no packages.
libpam-modules suggests no packages.
-- debconf information excluded
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2060676/+subscriptions
More information about the Ubuntu-sponsors
mailing list