Migrate to lastlog2

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Migrate lastlog and all functionality associated with it (e.g. pam_lastlog, the PAM stack) to lastlog2.

Owner

Name: Iker Pedrosa
Email: <ipedrosa@redhat.com>

Current status

Targeted release: Fedora Linux 43
Last updated: 2025-02-14
[<link to devel-announce post will be added by Wrangler> Announced]
[<will be assigned by the Wrangler> Discussion thread]
FESCo issue: <will be assigned by the Wrangler>
Tracker bug: <will be assigned by the Wrangler>
Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

The Year 2038 problem (Y2038) poses a significant threat to systems relying on 32-bit time representations. It's crucial to address this before it impacts Fedora. This proposal suggests replacing the current lastlog utility with lastlog2, a robust and widely adopted solution already integrated into distributions like Debian and openSUSE.

lastlog reports the last login of a given user or of all users who did ever login on a system. The standard /var/log/lastlog implementation using lastlog.h from glibc uses a 32bit time_t in struct lastlog on bi-arch systems like x86-64 (so which can execute 64bit and 32bit binaries). So even if you have a pure 64bit system, on many architectures using glibc this leads to the Y2038 problem. lastlog2 is a Y2038 safe implementation of lastlog and it is considered as the natural replacement.

lastlog2 offers a comprehensive solution, including not just the lastlog2 binary for interacting with user login information, but also a dedicated library and a PAM module for seamless integration and accurate user tracking. Critically, lastlog2 provides a migration path for existing lastlog data.

Feedback

This Fedora System-Wide Change is open to feedback and other proposals from the community.

Benefit to Fedora

Y2038 safe: it addresses the core issue by using a time representation that avoids the Y2038 overflow.
SQLite3 backend: it leverages a modern and efficient database for storing login information.
PAM module integration: data collection is handled exclusively through a PAM module, allowing any tool to utilize the information without requiring modifications to existing packages. This ensures broad compatibility and avoids cascading changes.
Backward compatibility: output is designed to be as compatible as possible with the traditional lastlog format, minimizing disruption to existing workflows.
Data migration: it provides a mechanism to import existing data from the legacy /var/log/lastlog file, preserving valuable login history.
Scalability: the database size scales with the number of users, not the largest UID, offering improved performance and resource utilization, especially in environments with sparse UID allocation.

This change offers a proactive and well-supported solution to the Y2038 problem within Fedora, ensuring the continued reliability and security of the system. In short, lastlog2 is part of the util-linux project, which Fedora has been using for years, and which has been accepted by different communities such as Debian or OpenSuse as the ideal replacement for lastlog.

Scope

Proposal owners: shadow-utils, PAM and util-linux projects need to change their configuration to stop providing lastlog functionality and start providing lastlog2. authselect project needs to replace pam_lastlog by pam_lastlog2 in the PAM stack and update fedora content accordingly. Finally, util-linux will have to migrate the existing database from lastlog to lastlog2 format during the upgrade process.

Other developers: N/A

Release engineering: #Releng issue number

N/A

Policies and guidelines: N/A

Trademark approval: N/A

Alignment with the Fedora Strategy: N/A

Upgrade/compatibility impact

Nothing will be affected, since the old database format from lastlog will be automatically migrated to the new lastlog2 format.

How To Test

Two different scenarios come to my mind:

New system: once the system is correctly installed authenticate as a user and run lastlog2 for this user. The timestamp of the last login should match the one that recently happened.
Old system: once the system is correctly updated authenticate as a user and run lastlog2 for another user. The timestamp of the last login should have happened before the update happened.

User Experience

lastlog and pam_lastlog don't exist anymore and are replaced by lastlog2 and pam_lastlog2. They should behave in a similar manner to the aforementioned artifacts, thus no other change will be experienced by the user.

Dependencies

There are no other dependencies.

Contingency Plan

Contingency mechanism: If any change was committed revert it.
Contingency deadline: Just before beta freeze.
Blocks release? No

Documentation

Release Notes

Users should be informed that lastlog and pam_lastlog are replaced by lastlog2 and pam_lastlog2 in Fedora 43. In addition, the reasons for this change should be clearly explained. This FSWC proposal should be enough to understand the context, but if you have any doubts don't hesitate to contact the owner.

Search

Changes/Migrato to lastlog2

Contents