GNU bug report logs -
#64937
"who" reports funny dates
Previous Next
Reported by: Sven Joachim <svenjoac <at> gmx.de>
Date: Sat, 29 Jul 2023 16:42:01 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64937 in the body.
You can then email your comments to 64937 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Sat, 29 Jul 2023 16:42:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Sven Joachim <svenjoac <at> gmx.de>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Sat, 29 Jul 2023 16:42:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
A 32-bit "who" program reports funny login dates:
,----
| $ file src/who
| src/who: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=a897e4f7a6dfd45c9245594e3d0b20497472c66d, for GNU/Linux 3.2.0, with debug_info, not stripped
| $ src/who
| sven tty1 133589088-06-27 20:29
| sven pts/0 121346977-03-14 05:00 (:0)
| sven tty2 50067723-10-30 01:10
| sven pts/1 3442548-06-12 17:26 (:0)
`----
This is with current coreutils git (commit 3cb862ce5f1) configured with
"CC=gcc -m32" on Debian sid/amd64, but the same issue can also be seen
on plain i386. Originally reported by Jakub Wilk in
https://bugs.debian.org/1027135, and I noticed it myself after upgrading
an ancient machine to Debian 12 today.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Sat, 29 Jul 2023 19:45:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 29/07/2023 17:41, Sven Joachim wrote:
> A 32-bit "who" program reports funny login dates:
>
> ,----
> | $ file src/who
> | src/who: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=a897e4f7a6dfd45c9245594e3d0b20497472c66d, for GNU/Linux 3.2.0, with debug_info, not stripped
> | $ src/who
> | sven tty1 133589088-06-27 20:29
> | sven pts/0 121346977-03-14 05:00 (:0)
> | sven tty2 50067723-10-30 01:10
> | sven pts/1 3442548-06-12 17:26 (:0)
> `----
>
> This is with current coreutils git (commit 3cb862ce5f1) configured with
> "CC=gcc -m32" on Debian sid/amd64, but the same issue can also be seen
> on plain i386. Originally reported by Jakub Wilk in
> https://bugs.debian.org/1027135, and I noticed it myself after upgrading
> an ancient machine to Debian 12 today.
I think this is due to the unconditional use of 64 bit time_t.
In normal 64 bit mode, glibc organizes that the time_t is 32 bit for the utmp records,
however it doesn't do this in 32 bit mode, assuming that time_t is 32 bit.
If one configures with --disable-year2038, then 32 bit time_t is used in 32 bit mode,
and the problem is avoided. However that's a big hammer, disabling 64 bit time_t everywhere.
I tried a quick build with -D__WORDSIZE_TIME64_COMPAT32=1
which is what glibc uses to force the smaller time types.
However that didn't fix the issue, so I'll need to look a bit more,
and how to get only utmp access restricted to 32 bit types.
Note there was a related query recently to move away from the utmp
interface entirely, since it is currently restricted to 32 bit times,
and so will have year 2038 issues.
cheers,
Pádraig.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Sun, 30 Jul 2023 00:31:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Sven Joachim <svenjoac <at> gmx.de>:
bug acknowledged by developer.
(Sun, 30 Jul 2023 00:31:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 64937-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2023-07-29 12:44, Pádraig Brady wrote:
> I tried a quick build with -D__WORDSIZE_TIME64_COMPAT32=1
> which is what glibc uses to force the smaller time types.
> However that didn't fix the issue, so I'll need to look a bit more,
> and how to get only utmp access restricted to 32 bit types.
I looked into that, and installed the attached patches into Gnulib and
Coreutils respectively; these should work around the problem so I'll
boldly close the bug report.
These patches are quite a hack, though, and (obviously) stop working
after the year 2038.
What's Debian's and/or Fedora's plan for fixing <utmp.h>/<utmpx.h>'s
Y2038 bugs? (Or is the idea to remove the <utmp.h></utmpx.h> API before
2038? :-)
See:
https://lwn.net/Articles/925068/
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#utmp_types_and_APIs
[0001-readutmp-work-around-glibc-utmpx-bug.patch (text/x-patch, attachment)]
[0001-build-update-gnulib-submodule-to-latest.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Sun, 30 Jul 2023 11:03:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 64937-done <at> debbugs.gnu.org (full text, mbox):
On 30/07/2023 01:30, Paul Eggert wrote:
> On 2023-07-29 12:44, Pádraig Brady wrote:
>> I tried a quick build with -D__WORDSIZE_TIME64_COMPAT32=1
>> which is what glibc uses to force the smaller time types.
>> However that didn't fix the issue, so I'll need to look a bit more,
>> and how to get only utmp access restricted to 32 bit types.
>
> I looked into that, and installed the attached patches into Gnulib and
> Coreutils respectively; these should work around the problem so I'll
> boldly close the bug report.
>
> These patches are quite a hack, though, and (obviously) stop working
> after the year 2038.
>
> What's Debian's and/or Fedora's plan for fixing <utmp.h>/<utmpx.h>'s
> Y2038 bugs? (Or is the idea to remove the <utmp.h></utmpx.h> API before
> 2038? :-)
>
> See:
>
> https://lwn.net/Articles/925068/
>
> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#utmp_types_and_APIs
Thanks Paul.
Yes I think the consensus is to switch away from the utmp API,
which was recently discussed at:
https://lists.gnu.org/archive/html/coreutils/2023-06/msg00024.html
cheers,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Sun, 30 Jul 2023 12:37:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 2023-07-29 17:30 -0700, Paul Eggert wrote:
> On 2023-07-29 12:44, Pádraig Brady wrote:
>> I tried a quick build with -D__WORDSIZE_TIME64_COMPAT32=1
>> which is what glibc uses to force the smaller time types.
>> However that didn't fix the issue, so I'll need to look a bit more,
>> and how to get only utmp access restricted to 32 bit types.
I guess -D__WORDSIZE_TIME64_COMPAT32=1 does not cut it because
bits/wordsize.h #defines __WORDSIZE_TIME64_COMPAT32 as 0, overriding the
commandline definition.
> What's Debian's and/or Fedora's plan for fixing <utmp.h>/<utmpx.h>'s
> Y2038 bugs? (Or is the idea to remove the <utmp.h></utmpx.h> API
> before 2038? :-)
I don't really know. In the near future Debian plans to enable
-D_TIME_BITS=64 by default on most 32-bit architectures[1] though, and
then the utmp interface is going to break. I have notified the Debian
glibc maintainers[2], but the problem needs to be addressed by glibc
upstream.
> See:
>
> https://lwn.net/Articles/925068/
>
> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#utmp_types_and_APIs
Thanks for the links. And for fixing the bug. :-)
Cheers,
Sven
1. https://lists.debian.org/debian-devel/2023/05/msg00168.html
2. https://bugs.debian.org/1042562
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Sun, 30 Jul 2023 17:04:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 2023-07-30 04:02, Pádraig Brady wrote:
> Yes I think the consensus is to switch away from the utmp API,
> which was recently discussed at:
> https://lists.gnu.org/archive/html/coreutils/2023-06/msg00024.html
If I understand that discussion correctly, the idea is to switch from
utmp/utmpx to the systemd interface once systemd 254 comes out.
As it happens, systemd 254 was published Friday. It'd be good to get it
working with coreutils.
Thorsten's draft coreutils patches
<https://github.com/thkukuk/utmpx/tree/main/patches/coreutils> are a bit
long, and I'm hoping we can simplify this by packaging the fix inside
Gnulib (much as we already packaged the fix for <utmpx.h> not working on
32-bit GNU/Linux x86 and ARM when _TIME_BITS is 64[1]), so that we
needn't patch Coreutils other than to upgrade Gnulib version.
Is there any way to test this stuff easily on a platform like Fedora 38
that is running systemd 253? That is, can I merely build the systemd
libraries and link to them (how?), or would I have to replace the entire
systemd ecosystem?
[1]: https://lists.gnu.org/r/bug-gnulib/2023-07/msg00159.html
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Sun, 30 Jul 2023 17:41:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> If I understand that discussion correctly, the idea is to switch from
> utmp/utmpx to the systemd interface once systemd 254 comes out.
>
> As it happens, systemd 254 was published Friday.
It's already contained in Fedora Rawhide.
> It'd be good to get it working with coreutils.
I've installed that Fedora Rawhide from yesterday and am working on a
prototype...
> I'm hoping we can simplify this by packaging the fix inside
> Gnulib
Yes. Since not only coreutils, but also inetutils, uses the gnulib
module 'readutmp', it makes sense to put the fix into this gnulib
module.
Specific users, like 'uptime' in coreutils, can optimize things
afterwards when they need only a small subset, rather than all, of
the data returned by read_utmp().
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Mon, 31 Jul 2023 07:16:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 2023-07-31 00:08, Thorsten Kukuk wrote:
> 1. you need to extend ut_tv from 32bit time_t to 64bit time_t, or your
> patch will not survive 2038.
Yes, that's the plan. Gnulib's readutmp module already does this, in
apps that also use the year2038 or year2038-recommended modules (which
most do).
> 2. the string entries are size limited in struct utmp, but are not with
> libsystemd. So could be that you need to truncate device names, user
> names and host names.
This suggests that Gnulib needs to redo the readutmp API so that it's
not tied to struct utmpx's fixed string lengths. That's a bit of a
hassle but should be doable (change char array to char *). An advantage
is that Gnulib is a source-code library and so we can make binary- (and
even source-) incompatible changes to the API without too much trouble.
Thanks for the advice.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Mon, 31 Jul 2023 09:39:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Sun, Jul 30, Paul Eggert wrote:
> Thorsten's draft coreutils patches
> <https://github.com/thkukuk/utmpx/tree/main/patches/coreutils> are a bit
> long, and I'm hoping we can simplify this by packaging the fix inside
> Gnulib (much as we already packaged the fix for <utmpx.h> not working on
> 32-bit GNU/Linux x86 and ARM when _TIME_BITS is 64[1]), so that we
> needn't patch Coreutils other than to upgrade Gnulib version.
If you haven't seen yet, I made some time ago a mapping
between utmp struct entries and libsystemd functions:
https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md
But be aware:
1. you need to extend ut_tv from 32bit time_t to 64bit time_t, or your
patch will not survive 2038.
2. the string entries are size limited in struct utmp, but are not with
libsystemd. So could be that you need to truncate device names, user
names and host names.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 01 Aug 2023 23:17:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thorsten Kukuk wrote:
> If you haven't seen yet, I made some time ago a mapping
> between utmp struct entries and libsystemd functions:
> https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md
Thanks. This is helpful.
The only problem with this mapping is for the ut_line row, which
used to contain, for inbound ssh, the pty device name. It is not easy
to find the pty name in this situation; at least, none of the systemd
APIs and /run/systemd/** files that I looked at helped.
> But be aware:
> 1. you need to extend ut_tv from 32bit time_t to 64bit time_t, or your
> patch will not survive 2038.
This is already done by the 'year2038' module of Gnulib, which
coreutils and many other packages use.
> 2. the string entries are size limited in struct utmp, but are not with
> libsystemd. So could be that you need to truncate device names, user
> names and host names.
Thanks for the hint. Truncating would mean to introduce arbitrary limits,
which is against the GNU Coding Standards
<https://www.gnu.org/prep/standards/html_node/Semantics.html>. Hence
we'll happily use arbitrary-length strings in our code.
Paul Eggert wrote:
> This suggests that Gnulib needs to redo the readutmp API so that it's
> not tied to struct utmpx's fixed string lengths. That's a bit of a
> hassle but should be doable (change char array to char *). An advantage
> is that Gnulib is a source-code library and so we can make binary- (and
> even source-) incompatible changes to the API without too much trouble.
For the moment, I've extended the 'readutmp' module to use arbitrary-
length strings only when compiling with libsystemd.
Here are the changes I committed in gnulib.
2023-08-01 Bruno Haible <bruno <at> clisp.org>
readutmp: Small changes to reduce the code size on the coreutils side.
* m4/readutmp.m4 (gl_READUTMP): Test also for the ut_host field in
'struct utmpx' and 'struct utmp'.
* lib/readutmp.h (HAVE_STRUCT_XTMP_UT_HOST): New macro.
(UT_USER_SIZE): Define also as a macro. Set to -1 if
READUTMP_USE_SYSTEMD.
(UT_LINE_SIZE, UT_HOST_SIZE): New constants and macros.
2023-08-01 Bruno Haible <bruno <at> clisp.org>
readutmp: For year-2038 safety on Linux/{x86,arm}, use systemd APIs.
Suggested by Thorsten Kukuk <kukuk <at> suse.com> in
<https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/> and
<https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md>.
* m4/systemd.m4: New file.
* m4/readutmp.m4 (gl_READUTMP): Require gl_SYSTEMD_CHOICE. Set
READUTMP_LIB. Conditionally define READUTMP_USE_SYSTEMD.
* lib/readutmp.h: For READUTMP_USE_SYSTEMD, include <sys/time.h> and
<utmpx.h>.
(struct gl_utmp): New type.
(UTMP_STRUCT_NAME, UT_TIME_MEMBER, UT_EXIT_E_TERMINATION,
UT_EXIT_E_EXIT, UT_USER, HAVE_STRUCT_XTMP_UT_EXIT,
HAVE_STRUCT_XTMP_UT_ID, HAVE_STRUCT_XTMP_UT_PID): Define differently for
READUTMP_USE_SYSTEMD.
(UT_USER_SIZE): Don't define for READUTMP_USE_SYSTEMD.
(UT_TYPE_EQ, UT_TYPE_NOT_DEFINED, READ_UTMP_SUPPORTED): Define also for
READUTMP_USE_SYSTEMD.
(free_utmp): New declaration.
* lib/readutmp.c: Add new includes for READUTMP_USE_SYSTEMD.
(extract_trimmed_name): Adapt to READUTMP_USE_SYSTEMD.
(get_boot_time_uncached, get_boot_time, guess_pty_name): New functions.
(read_utmp): New implementation for READUTMP_USE_SYSTEMD.
(free_utmp): New function.
* tests/test-readutmp.c (main): At the end, invoke free_utmp.
* modules/readutmp (Files): Add m4/systemd.m4.
(Link): New section.
* modules/readutmp-tests (Makefile.am): Link test-readutmp with
READUTMP_LIB.
* NEWS: Mention the free_utmp function and the READUTMP_LIB link
requirement.
When the output of the 'test-readutmp' program without libsystemd is
==============================================================================
Here are the read_utmp results.
Flags: B = Boot, U = User Process
Termi‐ Flags
Time (GMT) User Device PID nation Exit B U
------------------- ------------------ ----------- ---------- ------ ---- - -
2023-07-30 09:25:15 reboot ~ 0 0 0 X
2023-07-30 09:25:31 runlevel ~ 53 0 0
2023-07-30 09:25:48 bruno seat0 1663 0 0 X
2023-07-30 09:25:48 bruno tty2 1663 0 0 X
2023-07-30 09:31:17 pts/1 3210 0 0
2023-07-31 23:36:52 bruno pts/3 30619 0 0 X
2023-08-01 15:19:26 other pts/4 40513 0 0 X
2023-08-01 19:02:20 pts/5 43376 0 1
==============================================================================
with libsystemd it is:
==============================================================================
Here are the read_utmp results.
Flags: B = Boot, U = User Process
Termi‐ Flags
Time (GMT) User Device PID nation Exit B U
------------------- ------------------ ----------- ---------- ------ ---- - -
2023-07-30 09:25:14 reboot ~ 0 0 0 X
2023-07-30 09:25:47 bruno seat0 1593 0 0 X
2023-07-30 09:25:47 bruno tty2 1593 0 0 X
2023-08-01 15:19:25 other sshd pts/4 40513 0 0 X
==============================================================================
The major changes are:
* Entries without BOOT_TIME or USER_PROCESS flag are gone. This includes
- runlevel and possibly "old time" / "new time" entries, which I don't know
how to get from systemd,
- entries for pseudo-terminals (xterm etc.) that are not login shells;
I don't know how to get them from systemd either, and (IMO) they were
uninteresting anyway,
- login shells that have exited.
* The reboot time is a little more precise, since the systemd code uses
the /proc/uptime virtual file.
* The pids now refer to the session leader, which is a parent (or ancestor)
of the process which has allocated the pty.
* In the ut_line field ("Device" column) I added extra info about the
service name, in this case "sshd". I imagine that is at least as useful as
knowing the pty name ("pts/4").
[0001-readutmp-For-year-2038-safety-on-Linux-x86-arm-use-s.patch (text/x-patch, attachment)]
[0002-readutmp-Small-changes-to-reduce-the-code-size-on-th.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 01 Aug 2023 23:41:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Here are the changes I committed in gnulib.
And here are the proposed changes for coreutils. Tested on a Fedora Rawhide
system, prepared from
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20230729.n.0.iso
The user-visible changes introduced by this change (when linking with
libsystemd) are, as far as I can see:
* "uptime", "users", "who -q" reports fewer users (because ptys without login
are not counted).
* "who -d" does not report anything any more.
* "who -r" does not report anything any more.
* "who -t" does not report anything any more.
* "who -u" does not report ptys without login any more. The order is arbitrary. Example:
Without systemd:
bruno seat0 2023-07-30 11:25 ? 1663 (login screen)
bruno tty2 2023-07-30 11:25 old 1663 (tty2)
bruno pts/3 2023-08-01 01:36 22:33 30619 (:0)
other pts/4 2023-08-01 17:19 06:50 40513 (::1)
With systemd:
other sshd pts/4 2023-08-01 17:19 06:50 40513 (::1)
bruno seat0 2023-07-30 11:25 ? 1593
bruno tty2 2023-07-30 11:25 old 1593
* pinky $USER
does not report a host any more (and thus does not spend time trying
to do a DNS lookup of "login screen" and "tty2"). Example:
Without systemd:
Login Name TTY Idle When Where
bruno Bruno Haible ?seat0 ????? 2023-07-30 11:25 login screen
bruno Bruno Haible tty2 2d 2023-07-30 11:25 tty2
bruno Bruno Haible pts/3 22:39 2023-08-01 01:36 :0
With systemd:
Login Name TTY Idle When Where
bruno Bruno Haible ?seat0 ????? 2023-07-30 11:25
bruno Bruno Haible tty2 2d 2023-07-30 11:25
The proposed patch is attached.
Note: Instead of the idiom
#ifdef UT_HOST_SIZE
(code for bounded ut_host)
#else
(code for unbounded ut_host)
#endif
one could also write
if (UT_HOST_SIZE >= 0)
{
(code for bounded ut_host)
}
else
{
(code for unbounded ut_host)
}
It's just a matter of style whether one prefers #ifs or implicit dead code.
[0001-maint-Update-after-gnulib-module-readutmp-changed.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Wed, 02 Aug 2023 08:07:03 GMT)
Full text and
rfc822 format available.
Message #40 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Tue, Aug 01, Bruno Haible wrote:
> Thorsten Kukuk wrote:
> > If you haven't seen yet, I made some time ago a mapping
> > between utmp struct entries and libsystemd functions:
> > https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md
>
> Thanks. This is helpful.
>
> The only problem with this mapping is for the ut_line row, which
> used to contain, for inbound ssh, the pty device name. It is not easy
> to find the pty name in this situation; at least, none of the systemd
> APIs and /run/systemd/** files that I looked at helped.
You mean you don't see a TTY on ssh sessions?
openssh is really special: it does not need a TTY for all kind of ssh
sessions, and thus only opens a TTY if needed after creating the
logind session. Thus the logind session does not contain the TTY
informations.
systemd-logind v254 provides now an interface for this case, which
allows to set the TTY later. For openssh you need this patch:
https://github.com/thkukuk/utmpx/blob/main/patches/openssh/logind-set-tty.patch
> The major changes are:
> * Entries without BOOT_TIME or USER_PROCESS flag are gone. This includes
> - runlevel and possibly "old time" / "new time" entries, which I don't know
> how to get from systemd,
systemd has no "runlevel", this entries don't exists.
I haven't found an application which creates "old time" / "new time"
entries, thus I think they can be ignored.
> - entries for pseudo-terminals (xterm etc.) that are not login shells;
> I don't know how to get them from systemd either, and (IMO) they were
> uninteresting anyway,
Yes, this is a problem or not, because on the other side, it solves a
problem. E.g.
* xterm creates entries for pseudo-terminals
* gnome-terminal does not create entries for pseudo-terminals
That was confusing in the past and is now consistent.
> * The pids now refer to the session leader, which is a parent (or ancestor)
> of the process which has allocated the pty.
Depends on your application. For the majority of applications, which we
evaluated, the PIDs reported by logind were identical to the PID from utmp.
> * In the ut_line field ("Device" column) I added extra info about the
> service name, in this case "sshd". I imagine that is at least as useful as
> knowing the pty name ("pts/4").
See above, this is a special openssh problem, we need to teach openssh
to report the TTY to logind, too.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Wed, 02 Aug 2023 09:57:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I wrote:
> The proposed patch is attached.
Oops, I missed a sizeof of the ut_id field. A corrected patch is attached.
[0001-maint-Update-after-gnulib-module-readutmp-changed.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Wed, 02 Aug 2023 16:43:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Thorsten Kukuk wrote:
> > The only problem with this mapping is for the ut_line row, which
> > used to contain, for inbound ssh, the pty device name. It is not easy
> > to find the pty name in this situation; at least, none of the systemd
> > APIs and /run/systemd/** files that I looked at helped.
>
> You mean you don't see a TTY on ssh sessions?
Yes, I see a session
uid=1001 user=other state=active active=Y remote=Y \
starttime=2023-08-01T15:19:25 seat=(null) leaderpid=40513 uiclass=user \
pamservice=sshd vt=-1 type=tty tty=(null) \
display=(null) desktop=(null) remotehost=::1 remoteuser=(null)
"uitype=tty" and "tty=(null)" don't make much sense together.
> openssh is really special: it does not need a TTY for all kind of ssh
> sessions, and thus only opens a TTY if needed after creating the
> logind session. Thus the logind session does not contain the TTY
> informations.
> systemd-logind v254 provides now an interface for this case, which
> allows to set the TTY later. For openssh you need this patch:
>
> https://github.com/thkukuk/utmpx/blob/main/patches/openssh/logind-set-tty.patch
That would make sense, yes. But I wonder:
- Why is it possible to set the "type" of the session to "tty", without
specifying a value for the "tty"?
- While at it: Shouldn't OpenSSH also provide a value for the "remote_user"
property?
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Wed, 02 Aug 2023 20:23:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Thorsten Kukuk wrote:
> And systemd/logind has a hack to delete this dummy entry, so that a
> fallback hack becomes active, which tries to determine the tty in
> another way. But this "hack" exists only for the dbus interface, not for
> libsystemd...
I see some hack in systemd/src/basic/terminal-util.c, indeed...
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Wed, 02 Aug 2023 21:37:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thorsten Kukuk wrote:
> > * The pids now refer to the session leader, which is a parent (or ancestor)
> > of the process which has allocated the pty.
>
> Depends on your application. For the majority of applications, which we
> evaluated, the PIDs reported by logind were identical to the PID from utmp.
Well, for me it's the opposite: For all desktops that I evaluated, the
PIDs reported by sd_session_get_leader — which is the replacement that you
recommend in <https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md>
(and I don't see any other one) — are different from the PID in utmp.
Only for inbound ssh do I see the same PID.
* Wayland-based desktops:
- GNOME:
systemd returns the PID of the gdm-session-worker process.
utmp contains the PID of the gdm-wayland-session process
(a child process of the former).
- KDE:
systemd returns the PID of the sddm-helper process.
utmp contains the PID of the startplasma-wayland process
(a child process of the former).
* X11-based desktops:
- Budgie:
systemd returns the PID of a lightdm process.
utmp contains the PID of the gnome-session-binary process
(a child process of the former).
- Cinnamon:
systemd returns the PID of a lightdm process.
utmp contains the PID of the cinnamon-session process
(a child process of the former).
- MATE:
systemd returns the PID of a lightdm process.
utmp contains the PID of the mate-session process
(a child process of the former).
- Xfce:
systemd returns the PID of a lightdm process.
utmp contains the PID of the xfce4-session process
(a child process of the former).
- SoaS:
systemd returns the PID of a lightdm process.
utmp contains the PID of a python3 process
(a child process of the former).
- LXQt:
systemd returns the PID of the sddm-helper process.
utmp contains the PID of the lxqt-session process
(a child process of the former).
- Sway:
systemd returns the PID of the sddm-helper process.
utmp contains the PID of the sway process
(a child process of the former).
- LXDE:
systemd returns the PID of the lxdm-session process.
utmp contains no PID at all! (Oh oh, looks like a bug in lxsession.)
Find attached the experiments' outputs.
Bruno
[outputs.tar.gz (application/x-compressed-tar, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 03 Aug 2023 05:37:03 GMT)
Full text and
rfc822 format available.
Message #55 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On Wed, Aug 02, Bruno Haible wrote:
> Thorsten Kukuk wrote:
> > openssh is really special: it does not need a TTY for all kind of ssh
> > sessions, and thus only opens a TTY if needed after creating the
> > logind session. Thus the logind session does not contain the TTY
> > informations.
> > systemd-logind v254 provides now an interface for this case, which
> > allows to set the TTY later. For openssh you need this patch:
> >
> > https://github.com/thkukuk/utmpx/blob/main/patches/openssh/logind-set-tty.patch
>
> That would make sense, yes. But I wonder:
> - Why is it possible to set the "type" of the session to "tty", without
> specifying a value for the "tty"?
sshd specifies a tty, but a dummy one: "sshd".
And systemd/logind has a hack to delete this dummy entry, so that a
fallback hack becomes active, which tries to determine the tty in
another way. But this "hack" exists only for the dbus interface, not for
libsystemd...
I know that Lennart Poettering had discussions about systemd and
sshd with the openssh developers to clean up some of the stuff and to
find better solutions, but without much success.
> - While at it: Shouldn't OpenSSH also provide a value for the "remote_user"
> property?
I think it should, but I don't know why they don't set "PAM_RUSER".
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Fri, 04 Aug 2023 06:34:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for doing all that work. I looked into it, and found a problem: a
command like "who /var/log/wtmp" stops working because the systemd
emulation of read_utmp only supports plain "who" (rougnly equivalent to
"who /var/run/utmp" on Fedora). So I installed it into coreutils, but
the default is systemd is disabled. This should give people time to
experiment with it.
Thorsten, is there some way to get the equivalent of /var/log/wtmp with
systemd?
Also, I simplified the use of the new readutmp interface a bit, by going
back to the old way where you simply call 'free' once to free the
storage. Although I toyed with the idea of simplifying readutmp.h
further, by moving most of it into readutmp.c and having just struct
gl_utmp public (this would simplify coreutils quite a bit), I ran out of
time and patience and decided to ship what I had. So I nstalled the
first ten attached patches into Gnulib, and the last patch into coreutils.
I haven't tested this with the latest systemd so there could well be
typos in that part of the code.
[0001-readutmp-simplify-extract_trimmed_name-via-ximemdup0.patch (text/x-patch, attachment)]
[0002-readutmp-go-back-to-simple-free.patch (text/x-patch, attachment)]
[0003-readutmp-fix-idx_t-FIXME-in-API.patch (text/x-patch, attachment)]
[0004-readutmp-pacify-Wstrict-prototypes.patch (text/x-patch, attachment)]
[0005-readutmp-fix-indentation.patch (text/x-patch, attachment)]
[0006-readutmp-switch-new-struct-to-struct-timespec.patch (text/x-patch, attachment)]
[0007-readutmp-systemd-supports-only-UTMP_FILE.patch (text/x-patch, attachment)]
[0008-readutmp-fix-comments.patch (text/x-patch, attachment)]
[0009-m4-systemd.m4-Fix-help-lineup.patch (text/x-patch, attachment)]
[0001-maint-Update-after-gnulib-module-readutmp-changed.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Fri, 04 Aug 2023 06:54:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Fri, Aug 04, Paul Eggert wrote:
> Thanks for doing all that work. I looked into it, and found a problem: a
> command like "who /var/log/wtmp" stops working because the systemd
> emulation of read_utmp only supports plain "who" (rougnly equivalent to
> "who /var/run/utmp" on Fedora). So I installed it into coreutils, but
> the default is systemd is disabled. This should give people time to
> experiment with it.
>
> Thorsten, is there some way to get the equivalent of /var/log/wtmp with
> systemd?
systemd does not collect wtmp data, because the applications don't
report this data to systemd. And I don't think it makes sense to
implement that or that such patches would be accepted by systemd
developers.
wtmp uses the same struct as utmp and thus faces the same problems,
including the Y2038 issue.
For this reason we (openSUSE/SUSE) switched to wtmpdb:
https://github.com/thkukuk/wtmpdb and don't support /var/log/wtmp
anymore.
And yes, "who /var/log/wtmp" will not work with this, too. But is this
really a required or usefull use case?
/usr/bin/last can give you the same output.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Fri, 04 Aug 2023 11:59:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> 0001-maint-Update-after-gnulib-module-readutmp-changed.patch
> +/* Work around <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109614>,
> + triggered by STREQ_LEN with a negative length. */
> +#if 11 <= __GNUC__
> +# pragma GCC diagnostic ignored "-Wstringop-overread"
> +#endif
The mentioned GCC bug is about a -Wanalyzer-use-after-free false positive.
I guess you meant https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110884 or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101778 ?
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Fri, 04 Aug 2023 13:46:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> Thanks for doing all that work. I looked into it, and found a problem: a
> command like "who /var/log/wtmp" stops working because the systemd
> emulation of read_utmp only supports plain "who" (roughly equivalent to
> "who /var/run/utmp" on Fedora).
Probably the FILE argument to 'who' and to 'users' should be deprecated?
Since in systemd mode, the only supported value for FILE is /var/run/utmp.
> Although I toyed with the idea of simplifying readutmp.h
> further, by moving most of it into readutmp.c and having just struct
> gl_utmp public (this would simplify coreutils quite a bit), I ran out of
> time and patience and decided to ship what I had.
Yes, I see how much contortions (strncpy etc.) these not-NUL-terminated
strings cause. And two separate code paths, one for the systemd mode and
one for all other platforms, is not ideal from the code coverage/testing/QA
perspective either.
I didn't tackle this, because before the add_utmp function existed, it
would have caused many extra malloc() calls on all platforms.
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Sun, 06 Aug 2023 19:45:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2023-08-04 04:58, Bruno Haible wrote:
> The mentioned GCC bug is about a -Wanalyzer-use-after-free false positive.
> I guess you meanthttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=110884 or
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101778 ?
Thanks for catching that. Yes, it should be 110884. I installed the
attached to Gnulib.
[0001-readutmp-fix-comment-bug-ID.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Sun, 06 Aug 2023 20:01:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 2023-08-03 23:53, Thorsten Kukuk wrote:
> And yes, "who /var/log/wtmp" will not work with this, too. But is this
> really a required or usefull use case?
> /usr/bin/last can give you the same output.
Sure, but some people use "who" for that.[1][2][3] This is partly
because "who" predates "last".
How does "last" emulate /var/log/wtmp using systemd?
Also, what about /var/log/btmp? That is, what is the systemd substitute
for "who /var/log/btmp" or "last -f /var/log/btmp"?
[1]: https://linuxhandbook.com/who-command/
[2]: https://linuxtldr.com/who-command/
[3]: https://kamotora.net/system/linux/check-btmp-wtmp-utmp/
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Sun, 06 Aug 2023 20:08:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 2023-08-06 13:00, Paul Eggert wrote:
> How does "last" emulate /var/log/wtmp using systemd?
Oh, I see from <https://github.com/thkukuk/wtmpdb> that wtmpdb comes
with its own "last". Is the plan to migrate this code into util-linux
"last", or simply to kill off util-linux "last"? Similarly for
util-linux utmpdmp, procps "w", etc.
Also, the question about /var/adm/btmp remains.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Sun, 06 Aug 2023 21:07:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On Sun, Aug 06, Paul Eggert wrote:
> On 2023-08-03 23:53, Thorsten Kukuk wrote:
> > And yes, "who /var/log/wtmp" will not work with this, too. But is this
> > really a required or usefull use case?
> > /usr/bin/last can give you the same output.
>
> Sure, but some people use "who" for that.[1][2][3] This is partly
> because "who" predates "last".
Somebody wrote some weeks ago: only because there was a Unix system
40 years ago nobody remembers anymore today with this limitations, there is
no reason for Linux to stick with this limitations.
SysV Init is gone and the majority does not miss it, and I don't see a
reason why "who /var/log/wtmp" needs to stay.
> How does "last" emulate /var/log/wtmp using systemd?
No, systemd handles current sessions, no historic data.
> Also, what about /var/log/btmp? That is, what is the systemd substitute
> for "who /var/log/btmp" or "last -f /var/log/btmp"?
Is there somebody really using btmp? Beside that it is really unreliable
since nearly no application is writing it, I asked on several mailing
lists and nobody answered.
Thorsten
> [1]: https://linuxhandbook.com/who-command/
> [2]: https://linuxtldr.com/who-command/
> [3]: https://kamotora.net/system/linux/check-btmp-wtmp-utmp/
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Sun, 06 Aug 2023 21:12:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On Sun, Aug 06, Paul Eggert wrote:
> On 2023-08-06 13:00, Paul Eggert wrote:
>
> > How does "last" emulate /var/log/wtmp using systemd?
>
> Oh, I see from <https://github.com/thkukuk/wtmpdb> that wtmpdb comes
> with its own "last". Is the plan to migrate this code into util-linux
> "last", or simply to kill off util-linux "last"? Similarly for
> util-linux utmpdmp, procps "w", etc.
util-linux will merge lastlog2, I have no idea about wtmpdb, this wasn't
a topic yet before my vacation.
procps-ng kills reading files directly and will use systemd, patch got
accepted but not yet merged.
The current patches for util-linux do the same.
I haven't looked at the latest PR for shadow, but they planned the same.
So nobody seems to care about "backward compatibily" with a time
where tools like "last" did not yet exist.
> Also, the question about /var/adm/btmp remains.
Is there a use-case, for which it is __reliable__ useable?
Until now, nobody could tell me one and nobody cared.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Mon, 07 Aug 2023 02:22:01 GMT)
Full text and
rfc822 format available.
Message #85 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 2023-08-06 14:10, Thorsten Kukuk wrote:
> On Sun, Aug 06, Paul Eggert wrote:
>
>> On 2023-08-06 13:00, Paul Eggert wrote:
>>
>>> How does "last" emulate /var/log/wtmp using systemd?
>>
>> Oh, I see from <https://github.com/thkukuk/wtmpdb> that wtmpdb comes
>> with its own "last". Is the plan to migrate this code into util-linux
>> "last", or simply to kill off util-linux "last"? Similarly for
>> util-linux utmpdmp, procps "w", etc.
>
> util-linux will merge lastlog2, I have no idea about wtmpdb, this wasn't
> a topic yet before my vacation.
Does lastlog2 store only the last login of each user? If so, it won't
work for a command like "last eggert", which outputs all the times that
I've logged in since wtmp was rotated.
> procps-ng kills reading files directly and will use systemd, patch got
> accepted but not yet merged.
> The current patches for util-linux do the same.
> I haven't looked at the latest PR for shadow, but they planned the same.
>
> So nobody seems to care about "backward compatibily" with a time
> where tools like "last" did not yet exist.
Hmm, well I guess I care. (Call me an old-timer. :-) Admittedly I care
more about usage like "last eggert".
>> Also, the question about /var/adm/btmp remains.
>
> Is there a use-case, for which it is __reliable__ useable?
I don't know what you mean by __reliable__. Certainly there are commands
that use /var/adm/btmp. util-linux's "lastb" command uses it, for
example. Will lastb stop working?
> Until now, nobody could tell me one and nobody cared.
Perhaps you're not talking to the right people? I can find a reasonable
amount of discussion about this stuff. For example, even if we restrict
our attention to btmp, a Google search using the query "lastb btmp"
returned 68,200 results for me just now, with many results on
serverfault.com, stackexchange.com, linuxhint.com, etc.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Mon, 07 Aug 2023 02:40:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 2023-08-06 14:06, Thorsten Kukuk wrote:
> SysV Init is gone and the majority does not miss it, and I don't see a
> reason why "who /var/log/wtmp" needs to stay.
I don't want to get into the middle of another systemd vs init battle.
But I don't see why this is relevant to that battle. Fedora 38 runs
systemd, for example, and it still maintains /var/log/wtmp. Likewise for
Ubuntu 23.04.
> Is there somebody really using btmp? Beside that it is really unreliable
> since nearly no application is writing it, I asked on several mailing
> lists and nobody answered.
Although Ubuntu does not maintain /var/log/btmp, Fedora does. I just
tested my Fedora 38 workstation, and /var/log/btmp records failed logins
back when I installed Fedora on it. Attackers on the Internet try to log
in to this workstation via ssh every few minutes. Logs like btmp could
be useful for forensics if an attack succeeds.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Mon, 07 Aug 2023 11:23:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> Fedora 38 runs
> systemd, for example, and it still maintains /var/log/wtmp. Likewise for
> Ubuntu 23.04.
Well, these are the permissions of these files:
/var/run/utmp /var/log/wtmp /var/log/btmp owner
Ubuntu 23.04 rw-rw-r-- rw-rw-r-- rw-rw---- root:utmp
Debian 12 rw-rw-r-- rw-rw-r-- rw-rw---- root:utmp
Fedora Rawhide rw-rw-r-- rw-rw-r-- rw-rw---- root:utmp
context initrc_var_run_t wtmp_t faillog_t
openSUSE 15.5 rw-rw-r-- rw-rw-r-- rw-rw---- root:utmp
Slackware 14 rw-rw-r-- rw-rw-r-- rw------- root:utmp, btmp only root:root
Alpine 3.18 rw-rw-r-- rw-rw-r-- rw-rw---- root:utmp
Debian Hurd rw-rw-r-- rw-rw-r-- rw-rw---- root:utmp
Since the fact that /var/run/utmp and /var/log/wtmp are world-readable
implies that they are world-lockable and thus the DoS bug
https://sourceware.org/bugzilla/show_bug.cgi?id=24492 applies,
to me it's clear that both utmp and wtmp needs to go away rather
sooner than later. My guess is that Fedora and Ubuntu/Debian are only
waiting for 'who' (coreutils) and 'last' (util-linux / wtmpdb) to
stop accessing these two files.
> > Is there somebody really using btmp? Beside that it is really unreliable
> > since nearly no application is writing it, I asked on several mailing
> > lists and nobody answered.
I agree with Paul: When three books/blogs mention /var/log/btmp and the
ability to run "sudo who -a /var/log/btmp", and additionally a command
'lastb' exists, for "sudo lastb", we cannot ignore that.
> Although Ubuntu does not maintain /var/log/btmp
What do you mean by that? On Ubuntu 23.04, I just did a "ssh localhost"
with a wrong password, and then I see:
$ sudo who -a /var/log/btmp
LOGIN ssh:notty 2023-08-07 13:06 2564 id=
$ sudo lastb
bruno ssh:notty 127.0.0.1 Mon Aug 7 13:06 - 13:06 (00:00)
Similarly when there were several failed logins.
("sudo who /var/log/btmp" prints nothing, because it filters out the LOGIN
lines. "who -a /var/log/btmp" prints nothing, because it cannot open the
file.)
So, IMO, the conclusion is:
* The /var/log/wtmp argument to "who" and "users" should become deprecated.
* Whereas for /var/log/btmp we need to make an effort to continue supporting
it, in the same 'who' program that accesses the systemd API for utmp.
And access the time stamp in it as an unsigned 32-bit integer, like
Andreas Schwab proposed (already implemented).
This means:
(1) The API of the readutmp module should provide unlimited-length ut_user,
ut_host etc. fields always. No more #ifdef UT_USER_SIZE.
(2) The readutmp module should use a runtime 'if' rather than a compile-time
#if, in order to dispatch between the systemd backend and the file-based
backend.
I'll work on (1) today.
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Mon, 07 Aug 2023 18:27:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 2023-08-07 04:22, Bruno Haible wrote:
> Since the fact that /var/run/utmp and /var/log/wtmp are world-readable
> implies that they are world-lockable and thus the DoS bug
> https://sourceware.org/bugzilla/show_bug.cgi?id=24492 applies,
> to me it's clear that both utmp and wtmp needs to go away
Although that bug should be fixed, a fix doesn't require utmp and wtmp
to go away. It can instead be fixed as Davin McCall suggested in the
original bug report, by making the files not world-lockable. This should
be doable on GNU/Linux (and I expect on other platform that support
these files) by implementing his suggestion. Admittedly the fix has been
low priority, but that doesn't mean it's not doable.
> sooner than later. My guess is that Fedora and Ubuntu/Debian are only
> waiting for 'who' (coreutils) and 'last' (util-linux / wtmpdb) to
> stop accessing these two files.
It's not just those two programs. Emacs looks at utmp, for example, when
creating the symlinks it uses to implement its own file locking, because
symlink contents contain the boot time (so that Emacs can better
detect stale locks) and the boot time is retrieved from /var/run/utmp.
I expect that other programs look at utmp and/or wtmp, besides obvious
candidates like 'login'. A quick scan through my Ubuntu /usr/bin found
sessreg, for example; it was originally developed for X but is now used
elsewhere.
Of course a better scheme could be arranged than utmp/wtmp. The problem
is that it has not been arranged yet and progress in this area has been
slow.
>> Although Ubuntu does not maintain /var/log/btmp
>
> What do you mean by that?
Oh, my mistake. I checked a workstation that was behind a restrictive
firewall, and nobody had ever attempted to attack it. You're right,
Ubuntu maintains btmp.
> * The /var/log/wtmp argument to "who" and "users" should become deprecated.
If it is deprecated, we'll need a significant overlap period where the
system both maintains utmp/wtmp/btmp, and also supports an alternative
system. Ideally applications won't notice the transition, at least if
they're using the POSIX/glibc interfaces in <utmpx.h>.
> * Whereas for /var/log/btmp we need to make an effort to continue supporting
> it, in the same 'who' program that accesses the systemd API for utmp.
> And access the time stamp in it as an unsigned 32-bit integer, like
> Andreas Schwab proposed (already implemented).
Although going to unsigned 32-bit integers is an improvement, it stops
working in the year 2106 unless we install further hacks later. Better
would be to widen the ?tmp files time_t to 64 bits, as is done on most
other 64-bit platforms. This would require a flag-day conversion during
a software upgrade, but that's doable, and <utmpx.h>-based programs
should work after the upgrade is done.
> This means:
> (1) The API of the readutmp module should provide unlimited-length ut_user,
> ut_host etc. fields always. No more #ifdef UT_USER_SIZE.
> (2) The readutmp module should use a runtime 'if' rather than a compile-time
> #if, in order to dispatch between the systemd backend and the file-based
> backend.
>
> I'll work on (1) today.
Thanks. Both ideas sound good to me for Gnulib.
One issue with (1) is that readutmp.h currently defines a boatload of
macros like UT_USER_SIZE, UT_TIME_MEMBER and UT_EXIT_E_TERMINATION that
aren't needed if every platform simply uses struct gl_utmp. It'd be
simpler to remove those macros (or move them to readutmp.c). Although it
is also tempting to leave those macros in readutmp.h for backward
compatibility, that might be more trouble than it's worth, as readutmp.h
is already incompatible with how it was a week ago.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 12:25:01 GMT)
Full text and
rfc822 format available.
Message #97 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On Mon, Aug 07, Paul Eggert wrote:
> On 2023-08-07 04:22, Bruno Haible wrote:
>
> > sooner than later. My guess is that Fedora and Ubuntu/Debian are only
> > waiting for 'who' (coreutils) and 'last' (util-linux / wtmpdb) to
> > stop accessing these two files.
>
> It's not just those two programs. Emacs looks at utmp, for example, when
> creating the symlinks it uses to implement its own file locking, because
> symlink contents contain the boot time (so that Emacs can better
> detect stale locks) and the boot time is retrieved from /var/run/utmp.
Something emacs needs to get fixed. On musl libc systems like Alpine,
you don't have utmp nor wtmp.
Beside that the emacs heuristic to find backups of wmtp is very
questionable, it wouldn't match on any of my systems.
There are better ways to determine the boot time.
> I expect that other programs look at utmp and/or wtmp, besides obvious
> candidates like 'login'. A quick scan through my Ubuntu /usr/bin found
> sessreg, for example; it was originally developed for X but is now used
> elsewhere.
There are some few:
https://github.com/thkukuk/utmpx/blob/main/Y2038.md#depending-on-utmpwtmpbtmplastlog-directly
And yes, the list is incomplete.
But to be honest, the majority is only creating entries (no longer
necessary) or counting the number of logged in users.
Other don't work since a long time since nobody writes the entries they
are looking for (like e.g. adjtimex).
So it's not that worse as it looks first.
> >> Although Ubuntu does not maintain /var/log/btmp
> >
> > What do you mean by that?
>
> Oh, my mistake. I checked a workstation that was behind a restrictive
> firewall, and nobody had ever attempted to attack it. You're right,
> Ubuntu maintains btmp.
Does they really maintain btmp or is it just openssh, where you cannot
disable btmp entries?
In the last case, the file is pretty useless, as all failed logins via
other ways (e.g. login itself) are not logged.
I know that Fedora tries to maintain it via pam_lastlog.so, but do to
all the problems with this interface that module is deprecated and will
be removed in a future release.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 14:04:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Thorsten Kukuk wrote:
> On musl libc systems like Alpine,
> you don't have utmp nor wtmp.
But on Alpine Linux, I don't see a systemd nor a logind daemon.
How are logins meant to be recorded on this system?
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 14:30:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On Tue, Aug 08, Bruno Haible wrote:
> Thorsten Kukuk wrote:
> > On musl libc systems like Alpine,
> > you don't have utmp nor wtmp.
>
> But on Alpine Linux, I don't see a systemd nor a logind daemon.
> How are logins meant to be recorded on this system?
They don't record at all.
Which means tools like who just don't show anything. And emacs will
never find out the boot time with the current code.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 15:28:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 64937 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 8 Aug 2023 14:29:27 +0000, Thorsten Kukuk <kukuk <at> suse.com> said:
Thorsten> On Tue, Aug 08, Bruno Haible wrote:
>> Thorsten Kukuk wrote:
>> > On musl libc systems like Alpine,
>> > you don't have utmp nor wtmp.
>>
>> But on Alpine Linux, I don't see a systemd nor a logind daemon.
>> How are logins meant to be recorded on this system?
Thorsten> They don't record at all.
Thorsten> Which means tools like who just don't show anything. And emacs will
Thorsten> never find out the boot time with the current code.
What API do you suggest we use instead?
Robert
--
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 15:29:01 GMT)
Full text and
rfc822 format available.
Message #109 received at 64937 <at> debbugs.gnu.org (full text, mbox):
I wrote on 2023-08-02:
> I wrote:
> > The proposed patch is attached.
>
> Oops, I missed a sizeof of the ut_id field. A corrected patch is attached.
Oops, this causes a compilation error on OpenBSD:
In file included from ../../gllib/readutmp.c:22:
../../gllib/readutmp.h:216:50: error: no member named 'ut_id' in 'struct utmp'
enum { UT_ID_SIZE = sizeof (((STRUCT_UTMP *) 0)->ut_id) };
~~~~~~~~~~~~~~~~~~~ ^
This patch fixes it.
2023-08-08 Bruno Haible <bruno <at> clisp.org>
readutmp: Fix compilation error on OpenBSD (regr. 2023-08-02).
* lib/readutmp.h (UT_ID_SIZE): Define to a dummy if there is no ut_id
field.
diff --git a/lib/readutmp.h b/lib/readutmp.h
index 01964d2622..9f53246597 100644
--- a/lib/readutmp.h
+++ b/lib/readutmp.h
@@ -213,7 +213,11 @@ enum { UT_USER_SIZE = sizeof UT_USER ((STRUCT_UTMP *) 0) };
#if HAVE_GL_UTMP
enum { UT_ID_SIZE = -1 };
#else
+# if (HAVE_UTMPX_H ? HAVE_STRUCT_UTMPX_UT_ID : HAVE_STRUCT_UTMP_UT_ID)
enum { UT_ID_SIZE = sizeof (((STRUCT_UTMP *) 0)->ut_id) };
+# else
+enum { UT_ID_SIZE = 1 };
+# endif
# define UT_ID_SIZE UT_ID_SIZE
#endif
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 15:33:01 GMT)
Full text and
rfc822 format available.
Message #112 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> 0006-readutmp-switch-new-struct-to-struct-timespec.patch
> @@ -150,12 +150,11 @@ struct gl_utmp
> ⎣ ut_addr_v6 [u]int[4] glibc, musl, Android
> */
>
> -# include <utmp.h>
> # if !HAVE_DECL_GETUTENT
> struct utmp *getutent (void);
> # endif
> # define UTMP_STRUCT_NAME utmp
> -# define UT_TIME_MEMBER(UT) ((UT)->ut_time)
> +# define UT_TIME_MEMBER(UT) ((UT)->ut_ts.tv_sec)
> # define SET_UTMP_ENT setutent
> # define GET_UTMP_ENT getutent
> # define END_UTMP_ENT endutent
This causes a compilation error on OpenBSD, AIX, and Android:
On OpenBSD:
../../gllib/readutmp.c:76:20: error: no member named 'ut_ts' in 'struct utmp'
bool user_proc = IS_USER_PROCESS (ut);
^~~~~~~~~~~~~~~~~~~~
../../gllib/readutmp.h:297:36: note: expanded from macro 'IS_USER_PROCESS'
|| (UT_TYPE_NOT_DEFINED && UT_TIME_MEMBER (UT) != 0)))
^~~~~~~~~~~~~~~~~~~
../../gllib/readutmp.h:158:36: note: expanded from macro 'UT_TIME_MEMBER'
# define UT_TIME_MEMBER(UT) ((UT)->ut_ts.tv_sec)
~~~~ ^
On AIX:
"../../gllib/readutmp.c", line 76.20: 1506-022 (S) "ut_ts" is not a member of "const struct utmp".
make: 1254-004 The error code from the last command is 1.
On Android:
../../gllib/readutmp.c:76:20: error: no member named 'ut_ts' in 'struct utmp'; did you mean 'ut_tv'?
This patch fixes it.
2023-08-08 Bruno Haible <bruno <at> clisp.org>
readutmp: Fix compilation error on OpenBSD and AIX (regr. 2023-08-03).
* lib/readutmp.h (UT_TIME_MEMBER) [HAVE_UTMP_H]: Revert last change.
diff --git a/lib/readutmp.h b/lib/readutmp.h
index 9f53246597..043ae6df16 100644
--- a/lib/readutmp.h
+++ b/lib/readutmp.h
@@ -155,7 +155,7 @@ struct gl_utmp
struct utmp *getutent (void);
# endif
# define UTMP_STRUCT_NAME utmp
-# define UT_TIME_MEMBER(UT) ((UT)->ut_ts.tv_sec)
+# define UT_TIME_MEMBER(UT) ((UT)->ut_time)
# define SET_UTMP_ENT setutent
# define GET_UTMP_ENT getutent
# define END_UTMP_ENT endutent
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 16:12:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim wrote:
> Thorsten> They don't record at all.
> Thorsten> Which means tools like who just don't show anything. And emacs will
> Thorsten> never find out the boot time with the current code.
>
> What API do you suggest we use instead?
musl libc runs only on Linux. On Linux, you can use this approach from Gnulib:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/readutmp.c;h=4e1d7ec26bef6cba4474433f72c9079b61794b97;hb=HEAD#l96
lines 96..150.
Part of it may already be contained in emacs/src/filelock.c; I can't tell.
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 16:48:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 64937 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 08 Aug 2023 18:11:20 +0200, Bruno Haible <bruno <at> clisp.org> said:
Bruno> Robert Pluim wrote:
Thorsten> They don't record at all.
Thorsten> Which means tools like who just don't show anything. And emacs will
Thorsten> never find out the boot time with the current code.
>>
>> What API do you suggest we use instead?
Bruno> musl libc runs only on Linux. On Linux, you can use this approach from Gnulib:
Bruno> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/readutmp.c;h=4e1d7ec26bef6cba4474433f72c9079b61794b97;hb=HEAD#l96
Bruno> lines 96..150.
So either reading "/proc/uptime" or calling "sysinfo". Iʼm assuming
the former is just the latter written to a file as a string, which we
can then parse again and turn into an integer. How efficient :-)
Bruno> Part of it may already be contained in emacs/src/filelock.c; I can't tell.
No, that currently uses either sysctl (probably only on *BSD and
macOS) or utmp/wtmp.
Robert
--
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 17:03:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I wrote:
> > (1) The API of the readutmp module should provide unlimited-length ut_user,
> > ut_host etc. fields always. No more #ifdef UT_USER_SIZE.
> > (2) The readutmp module should use a runtime 'if' rather than a compile-time
> > #if, in order to dispatch between the systemd backend and the file-based
> > backend.
> >
> > I'll work on (1) today.
(1) done through the following patch.
It does not break coreutils. But coreutils can now be simplified through the
attached 0001-maint-Simplify-after-gnulib-changed.patch .
2023-08-08 Bruno Haible <bruno <at> clisp.org>
readutmp: Return entries with unbounded strings on all platforms.
Suggested by Paul Eggert in
<https://lists.gnu.org/archive/html/bug-gnulib/2023-07/msg00165.html>.
* m4/readutmp.m4 (gl_READUTMP): Test also whether struct utmp has an
ut_tv member, and whether struct utmp and struct utmpx have an
ut_session member.
* lib/readutmp.h (struct gl_utmp): Define always. Add ut_exit field.
(HAVE_GL_UTMP): Remove macro.
(UT_USER, UT_TIME_MEMBER, UT_PID, UT_TYPE_EQ, UT_TYPE_NOT_DEFINED,
UT_EXIT_E_TERMINATION, UT_EXIT_E_EXIT, STRUCT_UTMP): Define w.r.t.
struct gl_utmp.
(UT_USER_SIZE, UT_ID_SIZE, UT_LINE_SIZE, UT_HOST_SIZE): Define to -1
always.
(getutent): Remove declaration.
(HAVE_STRUCT_XTMP_UT_EXIT): Remove unused macro.
(HAVE_STRUCT_XTMP_UT_ID, HAVE_STRUCT_XTMP_UT_PID,
HAVE_STRUCT_XTMP_UT_HOST): Change to match the way coreutils uses these
macros.
* lib/readutmp.c (UT_USER, UT_TIME_MEMBER, UT_PID, UT_TYPE_EQ,
UT_TYPE_NOT_DEFINED, IS_USER_PROCESS, UT_EXIT_E_TERMINATION,
UT_EXIT_E_EXIT, UT_USER_SIZE, UT_ID_SIZE, UT_LINE_SIZE, UT_HOST_SIZE):
Define w.r.t. struct utmpx or struct utmp.
(extract_trimmed_name): Don't use UT_USER or UT_USER_SIZE here.
(desirable_utmp_entry): Don't use UT_TIME_MEMBER or UT_USER here.
(struct utmp_alloc): Define always.
(add_utmp): Likewise. Add user_len, id_len, line_len, host_len,
termination, exit arguments. Don't require that user, id, line, host are
NUL-terminated. Assume user and host are non-NULL.
(finish_utmp): New function, extracted from read_utmp.
(read_utmp) [READUTMP_USE_SYSTEMD]: Update add_utmp invocations. Pass a
non-NULL user and a non-NULL host. Call finish_utmp.
(getutent): Move declaration from readutmp.h to here.
(copy_utmp_entry): Remove function.
(read_utmp) [UTMP_NAME_FUNCTION]: Replace variables n_read, n_alloc,
utmp with a 'struct utmp_alloc'. Use 'struct utmpx32' from
copy_utmp_entry here. Invoke add_utmp and finish_utmp.
(read_utmp) [!UTMP_NAME_FUNCTION]: Replace variables n_read, n_alloc,
utmp with a 'struct utmp_alloc'. Invoke add_utmp and finish_utmp.
* NEWS: Mention the API change.
[0001-readutmp-Return-entries-with-unbounded-strings-on-al.patch (text/x-patch, attachment)]
[0001-maint-Simplify-after-gnulib-changed.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 17:35:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On Tue, Aug 08, Robert Pluim wrote:
> >>>>> On Tue, 8 Aug 2023 14:29:27 +0000, Thorsten Kukuk <kukuk <at> suse.com> said:
> Thorsten> Which means tools like who just don't show anything. And emacs will
> Thorsten> never find out the boot time with the current code.
>
> What API do you suggest we use instead?
For me clock_gettime works very well:
https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md#determine-boot-time
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 19:33:01 GMT)
Full text and
rfc822 format available.
Message #127 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Thorsten Kukuk wrote:
> > What API do you suggest we use instead?
>
> For me clock_gettime works very well:
> https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md#determine-boot-time
Indeed, this provides the boot time with a resolution of 1 µsec. Whereas the
/proc/uptime approach only has a resolution of 10000 µsec. Thanks for the
suggestion.
2023-08-08 Bruno Haible <bruno <at> clisp.org>
readutmp: Get the boot time with higher precision.
Suggested by Thorsten Kukuk <kukuk <at> suse.com> in
<https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md#determine-boot-time>.
* lib/readutmp.c (get_boot_time_uncached): Try clock_gettime first.
diff --git a/lib/readutmp.c b/lib/readutmp.c
index 7ef5bfe84c..f7e43eb4a6 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -284,6 +284,31 @@ finish_utmp (struct utmp_alloc a)
static struct timespec
get_boot_time_uncached (void)
{
+ /* The clock_gettime facility returns the uptime with a resolution of 1 µsec.
+ It is available with glibc >= 2.14. In glibc < 2.17 it required linking
+ with librt. */
+# if __GLIBC__ + (__GLIBC_MINOR__ >= 17) > 2
+ struct timespec up;
+ if (clock_gettime (CLOCK_BOOTTIME, &up) >= 0)
+ {
+ struct timespec result;
+ /* equivalent to:
+ if (clock_gettime (CLOCK_REALTIME, &result) >= 0)
+ */
+ if (timespec_get (&result, TIME_UTC) >= 0)
+ {
+ if (result.tv_nsec < up.tv_nsec)
+ {
+ result.tv_nsec += 1000000000;
+ result.tv_sec -= 1;
+ }
+ result.tv_sec -= up.tv_sec;
+ result.tv_nsec -= up.tv_nsec;
+ return result;
+ }
+ }
+# endif
+
/* /proc/uptime contains the uptime with a resolution of 0.01 sec. */
FILE *fp = fopen ("/proc/uptime", "re");
if (fp != NULL)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 21:28:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 64937 <at> debbugs.gnu.org (full text, mbox):
I wrote:
> > (2) The readutmp module should use a runtime 'if' rather than a compile-time
> > #if, in order to dispatch between the systemd backend and the file-based
> > backend.
This patch implements it.
2023-08-08 Bruno Haible <bruno <at> clisp.org>
readutmp: Use classical implementation for files != /var/run/utmp.
* lib/readutmp.c (read_utmp_from_systemd): Renamed from read_utmp
[READUTMP_USE_SYSTEMD]. Remove file argument.
(read_utmp): Call it when the file argument is "/var/run/utmp".
diff --git a/lib/readutmp.c b/lib/readutmp.c
index f7e43eb4a6..66b25bc7ae 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -439,17 +439,9 @@ guess_pty_name (uid_t uid, const struct timespec at)
return NULL;
}
-int
-read_utmp (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
- int options)
+static int
+read_utmp_from_systemd (idx_t *n_entries, STRUCT_UTMP **utmp_buf, int options)
{
- /* The current implementation can imitate only UTMP_FILE. */
- if (strcmp (file, UTMP_FILE) != 0)
- {
- errno = ENOTSUP;
- return -1;
- }
-
/* Fill entries, simulating what a utmp file would contain. */
struct utmp_alloc a = {0};
@@ -602,7 +594,9 @@ read_utmp (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
return 0;
}
-# elif defined UTMP_NAME_FUNCTION /* glibc, musl, macOS, FreeBSD, NetBSD, Minix, AIX, IRIX, Solaris, Cygwin, Android */
+# endif
+
+# if defined UTMP_NAME_FUNCTION /* glibc, musl, macOS, FreeBSD, NetBSD, Minix, AIX, IRIX, Solaris, Cygwin, Android */
# if !HAVE_UTMPX_H && HAVE_UTMP_H && !HAVE_DECL_GETUTENT
struct utmp *getutent (void);
@@ -612,6 +606,12 @@ int
read_utmp (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
int options)
{
+# if READUTMP_USE_SYSTEMD
+ if (strcmp (file, UTMP_FILE) == 0)
+ /* Imitate reading UTMP_FILE, using systemd and Linux APIs. */
+ return read_utmp_from_systemd (n_entries, utmp_buf, options);
+# endif
+
/* Ignore the return value for now.
Solaris' utmpname returns 1 upon success -- which is contrary
to what the GNU libc version does. In addition, older GNU libc
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Tue, 08 Aug 2023 22:05:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Thorsten Kukuk wrote:
> > What API do you suggest we use instead?
>
> For me clock_gettime works very well:
> https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md#determine-boot-time
Now that I've implemented this method in gnulib's 'readutmp' module
and built coreutils with that, I see that it does not work "very well"
at all.
I have a VM running in VirtualBox, that I booted 6 days ago, then "saved"
it (i.e. all the state gets frozen) and resumed it today around 20:30 UTC.
In this VM, the test-readutmp program produces this output:
====================================================================================
Here are the read_utmp results.
Flags: B = Boot, U = User Process
Termi‐ Flags
Time (GMT) User Device PID nation Exit B U Host
------------------- ------------------ ----------- ---------- ------ ---- - - ----
2023-08-02 16:56:15 bruno seat0 1511 0 0 X :0
2023-08-08 15:47:48 reboot ~ 0 0 0 X
====================================================================================
Similarly,
====================================================================================
$ TZ=UTC ./who -a /var/run/utmp
system boot 2023-08-08 15:47
bruno ? seat0 2023-08-02 16:56 ? 1511 (:0)
====================================================================================
So, both programs show a "boot time" that is just 5 hours ago, at a moment when
the VM was in fact frozen.
Whereas the 'who' program, when it actually reads the /var/run/utmp file (via the
symlink /run/utmp), produces the correct time:
====================================================================================
$ TZ=UTC ./who -a /run/utmp
system boot 2023-08-02 16:55
run-level 5 2023-08-02 16:56
bruno + tty1 2023-08-02 16:56 old 1558 (:0)
pts/1 2023-08-02 17:31 2815 id=ts/1 term=0 exit=0
====================================================================================
All three methods from get_boot_time_uncached produce this wrong "boot time",
because they are all three based on
1) the kernel's ktime_get_boottime or ktime_get_boottime_ts64 function,
2) subtracting the returned value from the current time.
The description CLOCK_BOOTTIME in glibc's <bits/time.h> is:
/* Monotonic system-wide clock that includes time spent in suspension. */
# define CLOCK_BOOTTIME 7
Maybe that includes time spent in suspension. But it does not include time
spent in "saved" state of virtual machines. Thus is won't work right in cloud
environments.
I can't really argue that it's a kernel bug, since VirtualBox and VMs exist
for more than 10 years, and /proc/uptime and sysinfo() as well.
Therefore I think that
- The readutmp module should better pick the boot time from the real
/var/run/utmp file, and ignore the rest of this file (in systemd mode).
- We still don't have a reliable way of getting the boot time on
Alpine Linux, since the /var/run/utmp file there is empty.
- The effort to get rid of /var/run/utmp has encountered a stumbling block.
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Wed, 09 Aug 2023 01:40:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 2023-08-08 05:24, Thorsten Kukuk wrote:
> Something emacs needs to get fixed. On musl libc systems like Alpine,
> you don't have utmp nor wtmp.
Yes, as Bruno mentioned, we know of no way to find the boot time on
Alpine. When Emacs cannot determine the boot time, it pretends that the
system booted in 1970.
> Beside that the emacs heuristic to find backups of wmtp is very
> questionable, it wouldn't match on any of my systems.
It should work on our department's old Solaris 10 system, which has
files /var/adm/wtmpx, /var/adm/wtmpx.0, /var/adm/wtmpx.1, ...,
/var/adm/wtmpx.9, each about a week older than its predecessor.
> There are better ways to determine the boot time.
If we could find these better ways, we could add them to Emacs etc. In
the meantime I'm not sure what we can do. As Bruno mentioned,
CLOCK_BOOTTIME doesn't work either. This area is a bit of a mess.
> Does they really maintain btmp or is it just openssh, where you cannot
> disable btmp entries?
Ubuntu 23.04 really maintains btmp. I just now deliberately used the
wrong password on a console, and an entry was created in btmp.
> I know that Fedora tries to maintain it via pam_lastlog.so, but do to
> all the problems with this interface that module is deprecated and will
> be removed in a future release.
Perhaps they'll remove it in 2038. :-) In the meantime, we still need a
substitute for utmp, wtmp, and btmp.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Wed, 09 Aug 2023 03:12:01 GMT)
Full text and
rfc822 format available.
Message #139 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks, I installed the attached to simplify a bit further. A nice
consequence of these recent changes is that we get to remove some pragmas.
The first patch is for Gnulib; the other two are for Coreutils.
[0001-readutmp-omit-pragma.patch (text/x-patch, attachment)]
[0001-pinky-who-omit-pragma.patch (text/x-patch, attachment)]
[0002-who-simplify-based-on-readutmp-changes.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Wed, 09 Aug 2023 14:30:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 64937 <at> debbugs.gnu.org (full text, mbox):
More info about this problem: I wrote
> I have a VM running in VirtualBox, that I booted 6 days ago, then "saved"
> it (i.e. all the state gets frozen) and resumed it today around 20:30 UTC.
> ...
> So, both programs show a "boot time" that is just 5 hours ago, at a moment when
> the VM was in fact frozen.
1) The issue can be more easily reproduced by simply setting the date
("sudo date MMDDhhmm") in a VM, be it in VirtualBox or QEMU.
The result of
(time now) - (kernel's uptime notion)
becomes wrong at that point.
2) Fedora Rawhide has the 'virtualbox-guest-additions' package installed
by default, and these guest additions contain a "time synchronization"
feature [1]. Within 5 seconds after resuming a VM from sleep, they
do effectively the same as a "sudo date MMDDhhmm" command.
So, all approaches that compute the boot time through a subtraction are
going to be wrong in these scenarios.
The better approach is really to read the boot time from a time stamp —
inside a file such as /var/run/utmp or /var/log/wtmp, or attached to
a file such as
/var/lib/systemd/random-seed (first file touched during boot)
/var/log/boot.log (one of the last files touched during boot).
And on Alpine Linux, while /var/run/utmp is empty, its time stamp is
essentially the boot time.
The approach used by Emacs, namely to look at the time stamp of
/var/run/random-seed, is therefore essentially one of the best approaches.
It just needs to also look at /var/lib/systemd/random-seed and - on Alpine
Linux - /var/run/utmp .
Bruno
[1] https://docs.oracle.com/en/virtualization/virtualbox/6.1/user/guestadditions.html#4.1.-Introduction-to-Guest-Additions
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Wed, 09 Aug 2023 19:32:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[For those cc'ed, the thread's at <https://bugs.gnu.org/64937#142>.]
On 2023-08-09 07:29, Bruno Haible wrote:
> And on Alpine Linux, while /var/run/utmp is empty, its time stamp is
> essentially the boot time.
>
> The approach used by Emacs, namely to look at the time stamp of
> /var/run/random-seed, is therefore essentially one of the best approaches.
> It just needs to also look at /var/lib/systemd/random-seed and - on Alpine
> Linux - /var/run/utmp .
Thanks for looking into this. Clearly Emacs had some catching up to do,
since it was using a location for the random-seed file that current
GNU/Linux distros no longer use. To try to fix this I installed the
attached patch to Emacs master on Savannah.
This patch does not address the problem for Alpine, nor I suspect for
Android. I suppose Alpine could use the timestamp of /var/run/utmp (or
is that /run/utmp?) but I don't know how 'configure' would reliably
detect it's being built or cross-built for Alpine. I'll cc this to
Natanael Copa, who does the Alpine ports for Emacs, to see whether he
can give advice.
Also, I don't know how Android records boot time so I'll cc this to Po
Lu, the main developer for Emacs on Android.
[0001-Adjust-to-random-seed-move.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Wed, 09 Aug 2023 21:00:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I wrote:
> So, all approaches that compute the boot time through a subtraction are
> going to be wrong in these scenarios.
>
> The better approach is really to read the boot time from a time stamp —
> inside a file such as /var/run/utmp or /var/log/wtmp, or attached to
> a file such as
> /var/lib/systemd/random-seed (first file touched during boot)
> /var/log/boot.log (one of the last files touched during boot).
>
> And on Alpine Linux, while /var/run/utmp is empty, its time stamp is
> essentially the boot time.
With the attached patches, the boot time returned by read_utmp() is stable
across 'sudo date MMDDhhmm' invocations.
On Linux distros, I found these files to be touched after boot:
/var/lib/systemd/random-seed (seen on distros with systemd, e.g. CentOS 7,
Fedora 27, Debian 9, Ubuntu 17.10, Arch 19.11,
Manjaro 17)
/var/run/utmp (seen on distros with OpenRC, e.g. Alpine Linux)
/var/lib/random-seed (seen on OpenSUSE 12.1, CentOS 5)
And, while at it, also on OpenBSD. It touches /var/db/host.random and
/var/run/utmp.
Bruno
2023-08-09 Bruno Haible <bruno <at> clisp.org>
readutmp: Return a boot time also on OpenBSD.
* lib/readutmp.h (BOOT_TIME, USER_PROCESS): Provide fallback
definitions.
* lib/readutmp.c (read_utmp_from_file) [__OpenBSD__]: Fake a BOOT_TIME
entry by looking at the time stamp of a specific file.
readutmp: Return a boot time also on Alpine Linux.
* lib/readutmp.c: Include stat-time.h.
(SIZEOF): New macro.
(read_utmp_from_file) [__linux__]: Fake a BOOT_TIME entry by looking
at the time stamp of a specific file.
* modules/readutmp (Depends-on): Add stat-time.
readutmp: Fix boot time in VMs after sleep state and date update.
* lib/readutmp.c (read_utmp_from_file): New function, extracted from
read_utmp.
(get_boot_time_uncached): Before all other approaches, try to find the
boot time in the /var/run/utmp file.
(read_utmp): Invoke read_utmp_from_file.
readutmp: Make it easier to filter for/against the boot-time entry.
* lib/readutmp.h (READ_UTMP_BOOT_TIME, READ_UTMP_NO_BOOT_TIME): New
enum items.
* lib/readutmp.c (desirable_utmp_entry, read_utmp_from_systemd):
Implement them.
(read_utmp): If no entries can match the given options, return
immediately.
[0001-readutmp-Make-it-easier-to-filter-for-against-the-bo.patch (text/x-patch, attachment)]
[0002-readutmp-Fix-boot-time-in-VMs-after-sleep-state-and-.patch (text/x-patch, attachment)]
[0003-readutmp-Return-a-boot-time-also-on-Alpine-Linux.patch (text/x-patch, attachment)]
[0004-readutmp-Return-a-boot-time-also-on-OpenBSD.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Wed, 09 Aug 2023 21:07:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> This patch does not address the problem for Alpine, nor I suspect for
> Android. I suppose Alpine could use the timestamp of /var/run/utmp (or
> is that /run/utmp?) but I don't know how 'configure' would reliably
> detect it's being built or cross-built for Alpine. I'll cc this to
> Natanael Copa, who does the Alpine ports for Emacs, to see whether he
> can give advice.
For Alpine Linux, in Gnulib, I've used the following approach:
Read the entire contents of /var/run/utmp, and if it contains no entry
with ut_type == BOOT_TIME, look at the time stamp of some files,
in particular /var/run/utmp. It doesn't require a configure test.
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 00:04:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> [For those cc'ed, the thread's at <https://bugs.gnu.org/64937#142>.]
>
> On 2023-08-09 07:29, Bruno Haible wrote:
>
>> And on Alpine Linux, while /var/run/utmp is empty, its time stamp is
>> essentially the boot time.
>> The approach used by Emacs, namely to look at the time stamp of
>> /var/run/random-seed, is therefore essentially one of the best
>> approaches.
>> It just needs to also look at /var/lib/systemd/random-seed and - on
>> Alpine
>> Linux - /var/run/utmp .
>
> Thanks for looking into this. Clearly Emacs had some catching up to
> do, since it was using a location for the random-seed file that
> current GNU/Linux distros no longer use. To try to fix this I
> installed the attached patch to Emacs master on Savannah.
>
> This patch does not address the problem for Alpine, nor I suspect for
> Android. I suppose Alpine could use the timestamp of /var/run/utmp (or
> is that /run/utmp?) but I don't know how 'configure' would reliably
> detect it's being built or cross-built for Alpine. I'll cc this to
> Natanael Copa, who does the Alpine ports for Emacs, to see whether he
> can give advice.
>
> Also, I don't know how Android records boot time so I'll cc this to Po
> Lu, the main developer for Emacs on Android.
The boot time is off limits to user programs on Android, for security
reasons. It should suffice to undefine BOOT_TIME_FILE there.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 00:15:01 GMT)
Full text and
rfc822 format available.
Message #157 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Po Lu wrote:
> > Also, I don't know how Android records boot time so I'll cc this to Po
> > Lu, the main developer for Emacs on Android.
>
> The boot time is off limits to user programs on Android, for security
> reasons.
No, it isn't. The attached file, when compiled and run under Termux (which
doesn't have particular permissions), prints e.g.:
from clock : 1691616762.476870660 = 2023-08-09 21:32:42.476870660
from sysinfo: 1691616762.329261637 = 2023-08-09 21:32:42.329261637
Note that this uses the kernel's uptime counter, so it will not work well
when the user changes the current time manually. But this is rare on Android.
Bruno
[foo.c (text/x-csrc, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 02:15:02 GMT)
Full text and
rfc822 format available.
Message #160 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Bruno Haible <bruno <at> clisp.org> writes:
> Po Lu wrote:
>> > Also, I don't know how Android records boot time so I'll cc this to Po
>> > Lu, the main developer for Emacs on Android.
>>
>> The boot time is off limits to user programs on Android, for security
>> reasons.
>
> No, it isn't. The attached file, when compiled and run under Termux (which
> doesn't have particular permissions), prints e.g.:
>
> from clock : 1691616762.476870660 = 2023-08-09 21:32:42.476870660
> from sysinfo: 1691616762.329261637 = 2023-08-09 21:32:42.329261637
>
> Note that this uses the kernel's uptime counter, so it will not work well
> when the user changes the current time manually. But this is rare on Android.
This uses the uptime counter (which also results in an SELinux denial
for me, but different Android distributions have SELinux policies of
varying strictness), which cannot establish the precise time the system
started, since time elapses between the read from the uptime counter and
the read from the RTC.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 06:23:01 GMT)
Full text and
rfc822 format available.
Message #163 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 2023-08-09 19:14, Po Lu wrote:
> This uses the uptime counter (which also results in an SELinux denial
> for me, but different Android distributions have SELinux policies of
> varying strictness), which cannot establish the precise time the system
> started
Emacs doesn't need a precise boot time. All it really needs is an
integer that uniquely identifies the current OS boot.
> since time elapses between the read from the uptime counter and
> the read from the RTC.
Emacs allows for up to one second of slop in computing the boot time.
(In other words, it assumes that reboots are at least one second apart.)
So if there are minor errors in computing the boot time it should be OK.
If the errors are greater than one second, though, lock-file may assume
that locks are stale when they're not.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 07:00:01 GMT)
Full text and
rfc822 format available.
Message #166 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 2023-08-09 19:14, Po Lu wrote:
>> This uses the uptime counter (which also results in an SELinux denial
>> for me, but different Android distributions have SELinux policies of
>> varying strictness), which cannot establish the precise time the system
>> started
>
> Emacs doesn't need a precise boot time. All it really needs is an
> integer that uniquely identifies the current OS boot.
>
>> since time elapses between the read from the uptime counter and
>> the read from the RTC.
>
> Emacs allows for up to one second of slop in computing the boot
> time. (In other words, it assumes that reboots are at least one second
> apart.) So if there are minor errors in computing the boot time it
> should be OK. If the errors are greater than one second, though,
> lock-file may assume that locks are stale when they're not.
OK, but the SELinux problem still stands in the way. There's an uptime
counter in the Settings app though -- I'll try to establish how that
works.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 09:39:01 GMT)
Full text and
rfc822 format available.
Message #169 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Natanael Copa <natanael.copa <at> gmail.com> writes:
> 2) Even if it does exist, there is no guarantee that the timestamp is
> correct. There are machines without RTC (Raspberry PI for example),
> and in this case the time stamp may end up to be the same every reboot
> (if correctly set up it should save the shutdown time for the reboot
> and set time to this on next boot, but there is no guarantee).
If so, doesn't that discount the possibility of deriving the boot time
from the timestamp of any particular file? Since AFAIU these machines
lacking a TOY clock are relatively widespread?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 10:26:01 GMT)
Full text and
rfc822 format available.
Message #172 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On Thu, 10 Aug 2023 17:38:10 +0800
Po Lu <luangruo <at> yahoo.com> wrote:
> Natanael Copa <natanael.copa <at> gmail.com> writes:
>
> > 2) Even if it does exist, there is no guarantee that the timestamp is
> > correct. There are machines without RTC (Raspberry PI for example),
> > and in this case the time stamp may end up to be the same every reboot
> > (if correctly set up it should save the shutdown time for the reboot
> > and set time to this on next boot, but there is no guarantee).
>
> If so, doesn't that discount the possibility of deriving the boot time
> from the timestamp of any particular file? Since AFAIU these machines
> lacking a TOY clock are relatively widespread?
That was sort of my point. It is better to avoid if possible. In emacs
case I believe it is.
-nc
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 10:31:02 GMT)
Full text and
rfc822 format available.
Message #175 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I wrote:
> > No, it isn't. The attached file, when compiled and run under Termux (which
> > doesn't have particular permissions), prints e.g.:
> >
> > from clock : 1691616762.476870660 = 2023-08-09 21:32:42.476870660
> > from sysinfo: 1691616762.329261637 = 2023-08-09 21:32:42.329261637
> >
> > Note that this uses the kernel's uptime counter, so it will not work well
> > when the user changes the current time manually. But this is rare on Android.
It works well enough, that I'm adding it to Gnulib, through the attached patch.
Po Lu wrote:
> This uses the uptime counter (which also results in an SELinux denial
> for me, but different Android distributions have SELinux policies of
> varying strictness)
How did you run the program, and which of the two calls (clock_gettime, sysinfo)
failed for you? Maybe it depends not only on the Android version and device,
but also on the permissions required by the app?
Bruno
[0001-readutmp-Return-a-boot-time-also-on-Android.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 12:09:01 GMT)
Full text and
rfc822 format available.
Message #178 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Hi,
currently testing current coreutils git checkout on a utmp/wtmp free
machine, looks good so far. Except there is a compile problem with this
patch:
On Tue, Aug 08, Bruno Haible wrote:
> 2023-08-08 Bruno Haible <bruno <at> clisp.org>
>
> readutmp: Get the boot time with higher precision.
> Suggested by Thorsten Kukuk <kukuk <at> suse.com> in
> <https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md#determine-boot-time>.
> * lib/readutmp.c (get_boot_time_uncached): Try clock_gettime first.
>
> diff --git a/lib/readutmp.c b/lib/readutmp.c
> index 7ef5bfe84c..f7e43eb4a6 100644
> --- a/lib/readutmp.c
> +++ b/lib/readutmp.c
> @@ -284,6 +284,31 @@ finish_utmp (struct utmp_alloc a)
> static struct timespec
> get_boot_time_uncached (void)
> {
> + /* The clock_gettime facility returns the uptime with a resolution of 1 µsec.
> + It is available with glibc >= 2.14. In glibc < 2.17 it required linking
> + with librt. */
> +# if __GLIBC__ + (__GLIBC_MINOR__ >= 17) > 2
> + struct timespec up;
Not sure how relevant this code still is, but currently I get with this:
lib/readutmp.c: In function 'get_boot_time_uncached':
lib/readutmp.c:326:35: error: declaration of 'up' shadows a previous local [-Werror=shadow]
326 | struct timespec up =
| ^~
lib/readutmp.c:286:19: note: shadowed declaration is here
286 | struct timespec up;
| ^~
cc1: all warnings being treated as errors
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 12:24:01 GMT)
Full text and
rfc822 format available.
Message #181 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Bruno Haible <bruno <at> clisp.org> writes:
> I wrote:
>> > No, it isn't. The attached file, when compiled and run under Termux (which
>> > doesn't have particular permissions), prints e.g.:
>> >
>> > from clock : 1691616762.476870660 = 2023-08-09 21:32:42.476870660
>> > from sysinfo: 1691616762.329261637 = 2023-08-09 21:32:42.329261637
>> >
>> > Note that this uses the kernel's uptime counter, so it will not work well
>> > when the user changes the current time manually. But this is rare on Android.
>
> It works well enough, that I'm adding it to Gnulib, through the attached patch.
>
> Po Lu wrote:
>> This uses the uptime counter (which also results in an SELinux denial
>> for me, but different Android distributions have SELinux policies of
>> varying strictness)
>
> How did you run the program, and which of the two calls (clock_gettime, sysinfo)
> failed for you? Maybe it depends not only on the Android version and device,
> but also on the permissions required by the app?
Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial
errors and errno set to EACCESS.
I think it is a bit of a stretch to ascribe this to an app's requested
permissions, though, since none of the listed permissions available to
user programs seems pertinent.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 12:26:01 GMT)
Full text and
rfc822 format available.
Message #184 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Po Lu wrote:
> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial
> errors and errno set to EACCESS.
Was this inside Termux, or inside the Emacs app?
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 12:39:01 GMT)
Full text and
rfc822 format available.
Message #187 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Thorsten Kukuk wrote:
> Not sure how relevant this code still is, but currently I get with this:
>
> lib/readutmp.c: In function 'get_boot_time_uncached':
> lib/readutmp.c:326:35: error: declaration of 'up' shadows a previous local [-Werror=shadow]
> 326 | struct timespec up =
> | ^~
> lib/readutmp.c:286:19: note: shadowed declaration is here
> 286 | struct timespec up;
> | ^~
> cc1: all warnings being treated as errors
This is merely a warning, and it's already gone after today's refactorings
in Gnulib. To get past it, either remove '-Werror' from the Makefile, or
bootstrap against the current Gnulib:
$ GNULIB_SRCDIR=<path of gnulib checkout>
$ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 12:50:02 GMT)
Full text and
rfc822 format available.
Message #190 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On Thu, Aug 10, Bruno Haible wrote:
> This is merely a warning, and it's already gone after today's refactorings
> in Gnulib. To get past it, either remove '-Werror' from the Makefile, or
> bootstrap against the current Gnulib:
Thanks, I know how to get past it, else I couldn't have tested the result ;)
I only wanted to make aware of it, so that it does not go lost, since this
warning doesn't happen in all configurations.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 13:06:01 GMT)
Full text and
rfc822 format available.
Message #193 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Bruno Haible <bruno <at> clisp.org> writes:
> Po Lu wrote:
>> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial
>> errors and errno set to EACCESS.
>
> Was this inside Termux, or inside the Emacs app?
Inside the Emacs app. I'll try Termux soon: maybe the target SDK
version is the culprit.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 13:22:03 GMT)
Full text and
rfc822 format available.
Message #196 received at 64937 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi, I had a quick look at the thread, and I have a few comments.
1) it is openrc's bootmisc (
https://github.com/OpenRC/openrc/blob/86efc43d0e0d7569f5d2e7a58b8c461ac9f7dae8/init.d/bootmisc.in#L197)
that creates /var/run/utmp. There is no guarantee that this exists. You
can for example run emacs in a alpine docker container.
2) Even if it does exist, there is no guarantee that the timestamp is
correct. There are machines without RTC (Raspberry PI for example), and in
this case the time stamp may end up to be the same every reboot (if
correctly set up it should save the shutdown time for the reboot and set
time to this on next boot, but there is no guarantee).
For emacs' use case I'd say the best solution would be to use uptime from
sysinfo(2) and assume system time is correct (NTP client should be running
at the time emacs is started).
-nc
On Wed, Aug 9, 2023 at 9:31 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> [For those cc'ed, the thread's at <https://bugs.gnu.org/64937#142>.]
>
> On 2023-08-09 07:29, Bruno Haible wrote:
>
> > And on Alpine Linux, while /var/run/utmp is empty, its time stamp is
> > essentially the boot time.
> >
> > The approach used by Emacs, namely to look at the time stamp of
> > /var/run/random-seed, is therefore essentially one of the best
> approaches.
> > It just needs to also look at /var/lib/systemd/random-seed and - on
> Alpine
> > Linux - /var/run/utmp .
>
> Thanks for looking into this. Clearly Emacs had some catching up to do,
> since it was using a location for the random-seed file that current
> GNU/Linux distros no longer use. To try to fix this I installed the
> attached patch to Emacs master on Savannah.
>
> This patch does not address the problem for Alpine, nor I suspect for
> Android. I suppose Alpine could use the timestamp of /var/run/utmp (or
> is that /run/utmp?) but I don't know how 'configure' would reliably
> detect it's being built or cross-built for Alpine. I'll cc this to
> Natanael Copa, who does the Alpine ports for Emacs, to see whether he
> can give advice.
>
> Also, I don't know how Android records boot time so I'll cc this to Po
> Lu, the main developer for Emacs on Android.
--
Natanael Copa
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 14:13:01 GMT)
Full text and
rfc822 format available.
Message #199 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Po Lu wrote:
> >> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial
> >> errors and errno set to EACCESS.
> >
> > Was this inside Termux, or inside the Emacs app?
>
> Inside the Emacs app.
Emacs does not have the following in AndroidManifest.xml, which Termux has:
<uses-permission android:name="android.permission.READ_LOGS"/>
<uses-permission android:name="android.permission.DUMP"/>
Maybe one of these makes the difference?
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Thu, 10 Aug 2023 15:31:01 GMT)
Full text and
rfc822 format available.
Message #202 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Natanael Copa wrote:
> There are machines without RTC (Raspberry PI for example), and in
> this case the time stamp may end up to be the same every reboot (if
> correctly set up it should save the shutdown time for the reboot and set
> time to this on next boot, but there is no guarantee).
Indeed, on a Raspi with Raspbian (Debian derivative), /var/run/utmp contains
a BOOT_TIME entry with time = 1970-01-01 00:00:05. Which is unusable.
The clock gets set during the boot process, apparently through NTP. Then,
some files get touched:
/var/lib/systemd/timers/stamp-apt-daily.timer
/var/lib/systemd/timers/stamp-apt-daily-upgrade.timer
/var/lib/apt/daily_lock
But I suspect that they may be touched at other moments than during boot.
Therefore here, the workaround with the file time stamps does not work.
But another workaround works:
2023-08-10 Bruno Haible <bruno <at> clisp.org>
readutmp: Fix the boot time returned on Raspbian.
* lib/readutmp.c (read_utmp_from_file): When the time of the BOOT_TIME
entry is very close to the Epoch, replace it with the time from the
"runlevel"/"~" entry.
diff --git a/lib/readutmp.c b/lib/readutmp.c
index b344d8294d..e383531474 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -369,6 +369,12 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
SET_UTMP_ENT ();
+# if defined __linux__ && !defined __ANDROID__
+ bool file_is_utmp = (strcmp (file, UTMP_FILE) == 0);
+ /* Timestamp of the "runlevel" entry, if any. */
+ struct timespec runlevel_ts = {0};
+# endif
+
void const *entry;
while ((entry = GET_UTMP_ENT ()) != NULL)
@@ -408,6 +414,13 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
struct UTMP_STRUCT_NAME const *ut = (struct UTMP_STRUCT_NAME const *) entry;
# endif
+ struct timespec ts =
+ #if (HAVE_UTMPX_H ? 1 : HAVE_STRUCT_UTMP_UT_TV)
+ { .tv_sec = ut->ut_tv.tv_sec, .tv_nsec = ut->ut_tv.tv_usec * 1000 };
+ #else
+ { .tv_sec = ut->ut_time, .tv_nsec = 0 };
+ #endif
+
a = add_utmp (a, options,
UT_USER (ut), strnlen (UT_USER (ut), UT_USER_SIZE),
#if (HAVE_UTMPX_H ? HAVE_STRUCT_UTMPX_UT_ID : HAVE_STRUCT_UTMP_UT_ID)
@@ -431,11 +444,7 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
#else
0,
#endif
- #if (HAVE_UTMPX_H ? 1 : HAVE_STRUCT_UTMP_UT_TV)
- (struct timespec) { .tv_sec = ut->ut_tv.tv_sec, .tv_nsec = ut->ut_tv.tv_usec * 1000 },
- #else
- (struct timespec) { .tv_sec = ut->ut_time, .tv_nsec = 0 },
- #endif
+ ts,
#if (HAVE_UTMPX_H ? HAVE_STRUCT_UTMPX_UT_SESSION : HAVE_STRUCT_UTMP_UT_SESSION)
ut->ut_session,
#else
@@ -443,6 +452,12 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
#endif
UT_EXIT_E_TERMINATION (ut), UT_EXIT_E_EXIT (ut)
);
+# if defined __linux__ && !defined __ANDROID__
+ if (file_is_utmp
+ && memcmp (UT_USER (ut), "runlevel", strlen ("runlevel") + 1) == 0
+ && memcmp (ut->ut_line, "~", strlen ("~") + 1) == 0)
+ runlevel_ts = ts;
+# endif
}
END_UTMP_ENT ();
@@ -450,9 +465,19 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
# if defined __linux__ && !defined __ANDROID__
/* On Alpine Linux, UTMP_FILE is not filled. It is always empty.
So, fake a BOOT_TIME entry, by getting the time stamp of a file that
- gets touched only during the boot process. */
+ gets touched only during the boot process.
+
+ On Raspbian, which runs on hardware without a real-time clock, during boot,
+ 1. the clock gets set to 1970-01-01 00:00:00,
+ 2. an entry gets written into /var/run/utmp, with ut_type = BOOT_TIME,
+ ut_user = "reboot", ut_line = "~", time = 1970-01-01 00:00:05 or so,
+ 3. the clock gets set to a correct value through NTP,
+ 4. an entry gets written into /var/run/utmp, with
+ ut_user = "runlevel", ut_line = "~", time = correct value.
+ In this case, copy the time from the "runlevel" entry to the "reboot"
+ entry. */
if ((options & (READ_UTMP_USER_PROCESS | READ_UTMP_NO_BOOT_TIME)) == 0
- && strcmp (file, UTMP_FILE) == 0)
+ && file_is_utmp)
{
bool have_boot_time = false;
for (idx_t i = 0; i < a.filled; i++)
@@ -460,12 +485,16 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
struct gl_utmp *ut = &a.utmp[i];
if (UT_TYPE_BOOT_TIME (ut))
{
+ /* Workaround for Raspbian: */
+ if (ut->ut_ts.tv_sec <= 60 && runlevel_ts.tv_sec != 0)
+ ut->ut_ts = runlevel_ts;
have_boot_time = true;
break;
}
}
if (!have_boot_time)
{
+ /* Workaround for Alpine Linux: */
const char * const boot_touched_files[] =
{
"/var/lib/systemd/random-seed", /* seen on distros with systemd */
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Fri, 11 Aug 2023 08:29:02 GMT)
Full text and
rfc822 format available.
Message #205 received at 64937 <at> debbugs.gnu.org (full text, mbox):
Bruno Haible <bruno <at> clisp.org> writes:
> Po Lu wrote:
>> >> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial
>> >> errors and errno set to EACCESS.
>> >
>> > Was this inside Termux, or inside the Emacs app?
>>
>> Inside the Emacs app.
>
> Emacs does not have the following in AndroidManifest.xml, which Termux has:
> <uses-permission android:name="android.permission.READ_LOGS"/>
> <uses-permission android:name="android.permission.DUMP"/>
>
> Maybe one of these makes the difference?
>
> Bruno
Alas, no. The test program still doesn't work, either in the Termux app
or in the Emacs app with those two permissions listed.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 08 Sep 2023 11:24:08 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org.
(Fri, 08 Nov 2024 15:48:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#64937; Package
coreutils.
(Fri, 08 Nov 2024 15:55:01 GMT)
Full text and
rfc822 format available.
Message #212 received at 64937 <at> debbugs.gnu.org (full text, mbox):
On 2024-11-08 06:25, Office wrote:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64937
>
> Hello Paul.
>
> I use Debian SID.
> coreutils/unstable,now 9.5-1+b1 amd64 [installed]
>
> and it seems there is again the error.
>
> file /run/utmp is not getting created
> VPN IPSec is not working
>
> PS.
> Sorry I'm not a Debian developer so I don't know the issue messaging
> process.
> I hope it helps to solve the problem.
As far as I know the machinery is in Coreutils now, if it is configured
properly. Evidently it's not for you, for Debian Sid. I suggest writing
to Debian <https://www.debian.org/Bugs/Reporting>.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 07 Dec 2024 12:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 167 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.