#1072237 libutempter: integrate with wtmpdb

Package:
src:libutempter
Source:
src:libutempter
Submitter:
Chris Hofstaedtler
Date:
2026-02-11 09:21:05 UTC
Severity:
normal
#1072237#5
Date:
2024-05-30 19:03:06 UTC
From:
To:
Hi,

per the discussion on debian-devel [1], we'll get a Y2038-safe
replacement for wtmp, named wtmpdb / libwtmpdb etc.
Please see if your package should integrate with it.

It is unclear to me if non-login-equivalent programs should write to
wtmpdb or not. login-equivalent programs write using libpam-wtmpdb.

Chris

[1] https://lists.debian.org/debian-devel/2024/04/msg00406.html
#1072237#12
Date:
2024-06-08 08:26:10 UTC
From:
To:
Not the maintainer, but doing so would require installing the wtmptb
database writable by group utmp.  There is also the problem that
libutempter does not have a configurable build system, and you would
probably have to write the code to add wtmpdb support yourself.

Personally I would be inclined to say that non-login sessions should not
be recorded in wtmpdb and call it a day.

Cheers,
       Sven
#1072237#19
Date:
2024-11-09 00:00:20 UTC
From:
To:
Control: retitle -1 libutempter: do not log errors when /run/utmp is not present

Agreed.

In the meantime it'd be great if libutempter would silently do
nothing if /run/utmp does not exist.

Chris
#1072237#28
Date:
2024-11-17 16:34:06 UTC
From:
To:
clone 1072237 -2
retitle -2 libutempter: log no errors when /run/utmp is absent
usertag -2 + utmp-disable
thanks

Hi Christian,
different topics. I'll clone the bug for silencing the utmp-absent
case.

Just to spell it out explicitly, wtmpdb is a permanent history store.
In contrast, /run/utmp, previously keeping track of *currently*
logged in sessions, is thus not replaced by wtmpdb and the closest
replacement are logind sessions.

I don't know if it makes sense for libutempter to register sessions
with logind; but nevertheless, logging errors for /run/utmp missing
should please be stopped.

Here's a wiki page with the info we currently know about:
https://wiki.debian.org/pam_lastlog2%20and%20wtmpdb#For_maintainers

Thanks,
Chris
#1072237#37
Date:
2025-04-18 10:32:40 UTC
From:
To:
Not sure, but I'm wondering whether the -ls xterm option is intended
to have a visible effect:

    Finally, -ls is not completely ignored, because xterm -ls -e does
    write a wtmp entry (if configured to do so), whereas xterm -e does
    not.
#1072237#42
Date:
2026-02-10 22:06:48 UTC
From:
To:
(that was quoting xterm's manpage)

fwiw xterm relies upon utempter to do what's appropriate.

In a quick check, that's since

Patch #188 - 2004/5/12 - XFree86 4.4.99.6

     * improve  ifdef's  for  utempter  library  to  omit direct calls to
       setutent() or getutent() (adapted from patch by Christian Biere).

The README for utempter says

	The utempter is a privileged helper used by libutempter library to manipulate
	utmp and wtmp files.

and (the documentation appears to be written in C) the last thing utempter
does if no errors stop it is this:

	(void) updwtmp(_PATH_WTMP, &ut);

utempter uses setgid, while systemd (whose documentation is per-line of
code no better than utempter) appears to require root privilege
(which of course is a big step backwards).
#1072237#45
Date:
2026-02-10 22:06:48 UTC
From:
To:
(that was quoting xterm's manpage)

fwiw xterm relies upon utempter to do what's appropriate.

In a quick check, that's since

Patch #188 - 2004/5/12 - XFree86 4.4.99.6

     * improve  ifdef's  for  utempter  library  to  omit direct calls to
       setutent() or getutent() (adapted from patch by Christian Biere).

The README for utempter says

	The utempter is a privileged helper used by libutempter library to manipulate
	utmp and wtmp files.

and (the documentation appears to be written in C) the last thing utempter
does if no errors stop it is this:

	(void) updwtmp(_PATH_WTMP, &ut);

utempter uses setgid, while systemd (whose documentation is per-line of
code no better than utempter) appears to require root privilege
(which of course is a big step backwards).
#1072237#50
Date:
2026-02-10 22:59:38 UTC
From:
To:
As I understand the doc, software should not call systemd directly,
but should use PAM, and more specifically, pam_systemd:

  pam_systemd - Register user sessions in the systemd login manager

Then, concerning the needed permissions, isn't this controlled by
PAM configuration?
#1072237#55
Date:
2026-02-10 23:38:10 UTC
From:
To:
presumably - but ultimately it's a matter of authentication.
How do you suppose xterm would accomplish that?
#1072237#58
Date:
2026-02-10 23:38:10 UTC
From:
To:
presumably - but ultimately it's a matter of authentication.
How do you suppose xterm would accomplish that?
#1072237#63
Date:
2026-02-11 00:13:05 UTC
From:
To:
I don't know how this works, but I'm wondering why you mentioned
authentication. The only thing that should be used concerning the
user is the PID of the process.
#1072237#68
Date:
2026-02-11 00:17:24 UTC
From:
To:
I meant, the PID of the process should be known, and information
associated with it (UID...) can then be used. I don't see the
need for a particular authentication.
#1072237#73
Date:
2026-02-11 00:21:06 UTC
From:
To:
man pam:

       pam - Pluggable Authentication Modules Library

...

DESCRIPTION
       PAM is a system of libraries that handle the authentication tasks of
       applications (services) on the system. The library provides a stable
       general interface (Application Programming Interface - API) that
       privilege granting programs (such as login(1) and su(1)) defer to to
       perform standard authentication tasks.

I'd suppose PAM wants more than a process-id,
and am asking how you suppose that could be accomplished.
#1072237#76
Date:
2026-02-11 00:21:06 UTC
From:
To:
man pam:

       pam - Pluggable Authentication Modules Library

...

DESCRIPTION
       PAM is a system of libraries that handle the authentication tasks of
       applications (services) on the system. The library provides a stable
       general interface (Application Programming Interface - API) that
       privilege granting programs (such as login(1) and su(1)) defer to to
       perform standard authentication tasks.

I'd suppose PAM wants more than a process-id,
and am asking how you suppose that could be accomplished.
#1072237#81
Date:
2026-02-11 03:54:19 UTC
From:
To:
I would have thought that there may be contexts where authentication
is not needed (e.g. because the user has already authentified
themselves at a higher level). But I really don't know how PAM works.
#1072237#86
Date:
2026-02-11 09:19:49 UTC
From:
To:
Barring problems that you might read about on oss-security, there's no
way that PAM is going to provide a way to bypass the permissions needed
to update systemd's replacement for wtmp.
#1072237#89
Date:
2026-02-11 09:19:49 UTC
From:
To:
Barring problems that you might read about on oss-security, there's no
way that PAM is going to provide a way to bypass the permissions needed
to update systemd's replacement for wtmp.