bug#65423: README-install contains invalid/outdated information about 32 bit time_t compared to NEWS in 9.3

[Osipov, Michael (IN IT IN)]

On 2023-08-21 21:25, Paul Eggert wrote:
On 8/21/23 05:51, Osipov, Michael (IN IT IN) via GNU coreutils Bug 
Reports wrote:
in 9.3 year 2038 support with 64 bit time_t was made required [1], 
here on HP-UX this is a bit problematic, but that's not the actual 
problem. The diff between 9.2 and 9.3 [2] says how this can be fixed 
on platforms supporting both 32 and 64 bit, on HP-UX it'd be simply 
'+DD64', and how to avoid with "ac_year2038_required=no", but README- 
install on master [3] still contains '--disable-year2038' which 
obviously does not work. It simply needs to be updated to the content 
of [2].


Sorry, I don't understand. Why does --disable-year2038 not work on HP-UX 
for bleeding-edge coreutils on Savannah?


It sounds like you're suggesting that we revert the attached patch, but 
I don't see how that would be correct as bleeding-edge coreutils/ 
configure no longer looks at ac_year2038_required.


No need to be sorry ;-), I understand where your confusion comes from 
and mine. I was talking about changes between 9.2 and 9.3 only. Looking 
at the changes you refer are solely on master at [1] and [2] which make 
year 2038 support optional again. So no action is required anymore.


I cannot compile everything in 64 bit mode since no one has written 
our old applications with portability in mind. It needs to remain 32 
bit for now. 


I suggest compiling coreutils in 64-bit mode now. You can keep compiling 
your other applications in 32-bit mode. Even though HP-UX's end of life 
is the end of 2025, it's possible you'll run across a stray HP-UX file 
today with timestamp after 2038, and basic coreutils apps like 'ls' 
should work with such files.


I agree, and those are just executables. Regardless of this, HPE says at 
least until end of 2025, it is at the end a business decision and I am 
doing IT, so not my responsibility ;-). I just make it run. The files we 
touch go even back to late 80s.


Please go ahead and close this issue, it will auto-resolve with 9.4.

Michael

[1] 
https://github.com/coreutils/coreutils/commit/ba128e628cfa0dd111cf235d965200d1cdf77f52
[2] 
https://github.com/coreutils/coreutils/commit/3f942cd03fce1a6cda87018306b50f803f08f350#diff-df1edefd8cc0b27219a375d046251a2e9e87fcef6c23767640f12d0b4f784c76L321

bug#65423: README-install contains invalid/outdated information about 32 bit time_t compared to NEWS in 9.3

[Paul Eggert]

On 8/21/23 05:51, Osipov, Michael (IN IT IN) via GNU coreutils Bug 
Reports wrote:
in 9.3 year 2038 support with 64 bit time_t was made required [1], here 
on HP-UX this is a bit problematic, but that's not the actual problem. 
The diff between 9.2 and 9.3 [2] says how this can be fixed on platforms 
supporting both 32 and 64 bit, on HP-UX it'd be simply '+DD64', and how 
to avoid with "ac_year2038_required=no", but README-install on master 
[3] still contains '--disable-year2038' which obviously does not work. 
It simply needs to be updated to the content of [2].


Sorry, I don't understand. Why does --disable-year2038 not work on HP-UX 
for bleeding-edge coreutils on Savannah?


It sounds like you're suggesting that we revert the attached patch, but 
I don't see how that would be correct as bleeding-edge 
coreutils/configure no longer looks at ac_year2038_required.



I cannot compile everything in 64 bit mode since no one has written our old applications with portability in mind. It needs to remain 32 bit for now. 


I suggest compiling coreutils in 64-bit mode now. You can keep compiling 
your other applications in 32-bit mode. Even though HP-UX's end of life 
is the end of 2025, it's possible you'll run across a stray HP-UX file 
today with timestamp after 2038, and basic coreutils apps like 'ls' 
should work with such files.From ba128e628cfa0dd111cf235d965200d1cdf77f52 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Mon, 8 May 2023 12:57:56 +0100
Subject: [PATCH] doc: adjust build instructions for disabling year 2038
 support

* README-install: Adjust the instructions as per recent gnulib updates.
---
 README-install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README-install b/README-install
index 6ab5b4f8c..bbc034951 100644
--- a/README-install
+++ b/README-install
@@ -58,7 +58,7 @@ Although 32-bit builds fail if that forces time_t to be 32 bits, this
 can be fixed by using 64-bit builds.  For example, on AIX where GCC
 defaults to 32 bits, one can use "./configure CC='gcc -maix64' AR='ar
 -X64'"; similarly, on Solaris one can configure with CC='gcc -m64'.
-If all else fails one can configure with ac_year2038_required=no;
+If all else fails one can configure with --disable-year2038;
 however, this will mishandle timestamps after 2038, and please file
 bug reports for any such situations.
 
-- 
2.41.0

bug#65423: README-install contains invalid/outdated information about 32 bit time_t compared to NEWS in 9.3

[Osipov, Michael (IN IT IN)]

Folks,

in 9.3 year 2038 support with 64 bit time_t was made required [1], here 
on HP-UX this is a bit problematic, but that's not the actual problem. 
The diff between 9.2 and 9.3 [2] says how this can be fixed on platforms 
supporting both 32 and 64 bit, on HP-UX it'd be simply '+DD64', and how 
to avoid with "ac_year2038_required=no", but README-install on master 
[3] still contains '--disable-year2038' which obviously does not work. 
It simply needs to be updated to the content of [2].


FTR: I cannot compile everything in 64 bit mode since no one has written 
our old applications with portability in mind. It needs to remain 32 bit 
for now.


Michael

[1] 
https://github.com/coreutils/coreutils/commit/ffd62ab92c259d513a419b4078a45f1c658dc774
[2] 
https://github.com/coreutils/coreutils/compare/v9.2...v9.3#diff-2646d31b27172b7564edd6b4e2116efd8ee5c0cb5355129e8ef9b53ed0ea01b4
[3] 
https://github.com/coreutils/coreutils/blob/20b9a015e5aa05c6ad58bda8e9fa963d217b05e3/README-install#L53-L63

bug#65408: nl: -d doesn't use ':' as second char if a single non-ASCII char is provided

[Daniel Hofstetter]

Hi,

According to the documentation, the section delimiter consists of at
least two characters, and if you omit the second character when using
-d/--section-delimiter, the second character is implied to be ':'.
However, this doesn't seem to be the case in nl 9.3 if I provide a
single non-ASCII char:

$ printf "a\nä:\nb" | nl -dä
1  a
2  ä:
3  b

If I add the ':' manually, I get the expected output:

$ printf "a\nä:\nb" | nl -dä:
1  a

  b

Regards,
Daniel

bug#65342: In Ubuntu 22.04 (unlike 20.04), sorting doesn't work properly

[Pádraig Brady]

tag 65342 notabug
close 65342
stop

more info below...

On 16/08/2023 16:55, Pl B wrote:

Source file:
rs1009150173,100202244031
rs1009150172,13853975996
rs1009150170,54321425962
rs1009150171,11378896079
rs1009150,171582090052

Ubuntu 20.04.5:
sort -t ',' /path/to/rs_srt_exp.txt
rs1009150,171582090052
rs1009150170,54321425962
rs1009150171,11378896079
rs1009150172,13853975996
rs1009150173,100202244031
(correct order)

elementary OS 7 (Ubuntu 22.04.3):
sort -t ',' /path/to/rs_srt_exp.txt
rs1009150170,54321425962
rs1009150171,11378896079
rs1009150,171582090052
rs1009150172,13853975996
rs1009150173,100202244031
(wrong order)

Python 3.10.12:
with open('/path/to/rs_srt_exp.txt') as src_file_opened:
 for elem in sorted(map(lambda line: line.rstrip().split(','),
src_file_opened)):
 print(elem)
['rs1009150', '171582090052']
['rs1009150170', '54321425962']
['rs1009150171', '11378896079']
['rs1009150172', '13853975996']
['rs1009150173', '100202244031']
(correct order)


-t is ineffective without -k
I suspect the differing orders were due to locale differences.
To get expected ordering you probably want something like:

  sort -t ',' -k1.3,1n -k2,2n

Note the --debug option is useful for identifying how sort is operating.

cheers,
Pádraig

bug#65342: In Ubuntu 22.04 (unlike 20.04), sorting doesn't work properly

[Pl B]

Source file:
rs1009150173,100202244031
rs1009150172,13853975996
rs1009150170,54321425962
rs1009150171,11378896079
rs1009150,171582090052

Ubuntu 20.04.5:
sort -t ',' /path/to/rs_srt_exp.txt
rs1009150,171582090052
rs1009150170,54321425962
rs1009150171,11378896079
rs1009150172,13853975996
rs1009150173,100202244031
(correct order)

elementary OS 7 (Ubuntu 22.04.3):
sort -t ',' /path/to/rs_srt_exp.txt
rs1009150170,54321425962
rs1009150171,11378896079
rs1009150,171582090052
rs1009150172,13853975996
rs1009150173,100202244031
(wrong order)

Python 3.10.12:
with open('/path/to/rs_srt_exp.txt') as src_file_opened:
for elem in sorted(map(lambda line: line.rstrip().split(','),
src_file_opened)):
print(elem)
['rs1009150', '171582090052']
['rs1009150170', '54321425962']
['rs1009150171', '11378896079']
['rs1009150172', '13853975996']
['rs1009150173', '100202244031']
(correct order)

bug#65331: tests/df/skip-rootfs.sh fails on WSL2

[mytec]

Hi,

On Windows WSL2 (1.2.5.0) running Ubuntu 22.04.3 LTS one test failed. I 
downloaded a source release (coreutils-9.3) and did: ./configure, make, make 
check.



Testsuite summary for GNU coreutils 9.3

# TOTAL: 643
# PASS:  526
# SKIP:  116
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./tests/test-suite.log
Please report to bug-coreutils@gnu.org



tests/df/skip-rootfs.sh

+ create_exe_shims_ /home/bill/Source/coreutils-9.3/./src
+ case $EXEEXT in
+ return 0
+ shift
+ test 0 '!=' 0
+ export PATH
+ print_ver_ df
+ require_built_ df
+ skip_=no
+ for i in "$@"
+ case " $built_programs " in
+ test no = yes
+ test yes = yes
+ local i
+ for i in $*
+ env df --version
df (GNU coreutils) 9.3
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjorn Granlund, David MacKenzie, and Paul Eggert.
+ timeout 10 df
Filesystem   1K-blocks   Used   Available Use% Mounted on
none  32891432  432891428   1% /mnt/wsl
none1952760828  911256876  1041503952  47% /usr/lib/wsl/drivers
none  32891432  032891432   0% /usr/lib/wsl/lib
/dev/sdc1055762868  187999384   814060012  19% /
none  32891432 9232891340   1% /mnt/wslg
rootfs32888184   193632886248   1% /init
none  32888216  032888216   0% /dev
none  3289143290032890532   1% /run
none  32891432  032891432   0% /run/lock
none  32891432  032891432   0% /run/shm
none  32891432  032891432   0% /run/user
tmpfs 4096  04096   0% /sys/fs/cgroup
none  32891432 7232891360   1% /mnt/wslg/versions.txt
none  32891432 7232891360   1% /mnt/wslg/doc
drvfs   1952760828  911256876  1041503952  47% /mnt/c
drvfs  17578309624 2777179008 14801130616  16% /mnt/e
snapfuse   128128   0 100% /snap/bare/5
snapfuse  2048   2048   0 100% /snap/btop/627
snapfuse  2048   2048   0 100% /snap/btop/622
snapfuse 65024  65024   0 100% /snap/core20/1950
snapfuse 65024  65024   0 100% /snap/core20/1974
snapfuse 75648  75648   0 100% /snap/core22/817
snapfuse 75648  75648   0 100% /snap/core22/858
snapfuse 93952  93952   0 100% 
/snap/gtk-common-themes/1535
snapfuse 54656  54656   0 100% /snap/snapd/19361
snapfuse 54656  54656   0 100% /snap/snapd/19457
snapfuse132992 132992   0 100% 
/snap/ubuntu-desktop-installer/1195
snapfuse132992 132992   0 100% 
/snap/ubuntu-desktop-installer/1202
+ df -a
+ grep '^rootfs' out
rootfs32888184   193632886248   1% /init
+ df
+ grep '^rootfs' out
rootfs32888184   193632886248   1% /init
+ fail=1
+ cat out
Filesystem   1K-blocks   Used   Available Use% Mounted on
none  32891432  432891428   1% /mnt/wsl
none1952760828  911256876  1041503952  47% /usr/lib/wsl/drivers
none  32891432  032891432   0% /usr/lib/wsl/lib
/dev/sdc1055762868  187999388   814060008  19% /
none  32891432 9232891340   1% /mnt/wslg
rootfs32888184   193632886248   1% /init
none  32888216  032888216   0% /dev
none  3289143290032890532   1% /run
none  32891432  032891432   0% /run/lock
none  32891432  032891432   0% /run/shm
none  32891432  032891432   0% /run/user
tmpfs 4096  04096   0% /sys/fs/cgroup
none  32891432 7232891360   1% /mnt/wslg/versions.txt
none  32891432 7232891360   1% /mnt/wslg/doc
drvfs   1952760828  911256876  1041503952  47% /mnt/c
drvfs  17578309624 2777182208 14801127416  16% /mnt/e
snapfuse   128128   0 100% /snap/bare/5
snapfuse  2048   2048   0 100% /snap/btop/627
snapfuse  2048   2048   0 100% /snap/btop/622
snapfuse 65024  65024   0 100% /snap/core20/1950
snapfuse 65024  65024  

bug#65255: uptime's boot time is inconsistent after VM sleep & resume

[Paul Eggert]

On 2023-08-15 14:23, Bruno Haible wrote:

The other patch I mentioned, from
https://lists.gnu.org/archive/html/coreutils/2023-08/msg00028.html  ,
is also needed, for the "VM saved/sleep" change on NetBSD, OpenBSD, Minix,
as far as I understand.

Also, a typo in NEWS: s/Minux/Minix/


Thanks, I had missed that patch. I installed it and fixed the NEWS typo.

bug#65269: Possible null pointer dereference on the function cycle_check in rm

[Paul Eggert]

On 2023-08-14 00:05, Haoxin Tu wrote:

if the function `fts_read` get a return value of
NULL and the malloc from `fts->fts_cycle.state = malloc (sizeof
*fts->fts_cycle.state)` (Line 62 in fts_cycle.c) is NULL, the pointer
`fts->fts_cycle.state` will still keep 0 before the free operation `free
(sp->fts_cycle.state);` (Line 159 in fts_cycle.c), leading to free of
invalid address.


I don't see a problem, since 'free (0)' is valid and does nothing.

bug#65310: test failure on Alpine Linux: tests/sort/sort-debug-keys

[Bruno Haible]

Pádraig Brady wrote:
> The fact that ',' isn't used as the decimal point is surprising,
> and is what's causing the test to fail.

Ah, I see. Yes, for some tests one only needs a fr_FR.UTF-8 that supports
UTF-8 in LC_CTYPE, whereas for other tests it also needs to support the
LC_NUMERIC category correctly.

> The attached adds an extra guard to the test to skip this portion
> if ',' is not in fact the decimal point.

Thanks!

Bruno

bug#65255: uptime's boot time is inconsistent after VM sleep & resume

[Bruno Haible]

Paul Eggert wrote:
> Thanks for the further comments. I installed your patch, along with the 
> attached additional patches.

The other patch I mentioned, from
https://lists.gnu.org/archive/html/coreutils/2023-08/msg00028.html ,
is also needed, for the "VM saved/sleep" change on NetBSD, OpenBSD, Minix,
as far as I understand.

Also, a typo in NEWS: s/Minux/Minix/

Bruno

bug#65255: uptime's boot time is inconsistent after VM sleep & resume

[Paul Eggert]

Thanks for the further comments. I installed your patch, along with the 
attached additional patches. The first makes 'uptime' a bit more 
resilient in the case of utmp and other failures, and the second adds 
NEWS items as per your comments.From 1ea34cbf6a235f2436a3265ab9ded6f04748051e Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 15 Aug 2023 14:00:54 -0700
Subject: [PATCH 1/2] uptime: be more generous about read_utmp failure

* src/uptime.c (print_uptime): Check for overflow
when computing uptime.  Use C99-style decl after statements.
Do not let an idx_t value go negative.
(print_uptime, uptime): Be more generous about read_utmp failures,
or when read_utmp does not report the boot time.  Instead of
failing, warn but keep going, printing the information that we did
get, and then exit with nonzero status.
(print_uptime): Return the desired exit status.  Caller changed.
---
 src/uptime.c | 77 +++-
 1 file changed, 46 insertions(+), 31 deletions(-)

diff --git a/src/uptime.c b/src/uptime.c
index 813d29430..928829dfc 100644
--- a/src/uptime.c
+++ b/src/uptime.c
@@ -17,9 +17,11 @@
 /* Created by hacking who.c by Kaveh Ghazi gh...@caip.rutgers.edu.  */
 
 #include 
-#include 
 
+#include 
+#include 
 #include 
+
 #include "system.h"
 
 #if HAVE_SYSCTL && HAVE_SYS_SYSCTL_H && ! defined __GLIBC__
@@ -43,19 +45,11 @@
   proper_name ("David MacKenzie"), \
   proper_name ("Kaveh Ghazi")
 
-static void
-print_uptime (idx_t n, struct gl_utmp const *this)
+static int
+print_uptime (idx_t n, struct gl_utmp const *utmp_buf)
 {
-  idx_t entries = 0;
+  int status = EXIT_SUCCESS;
   time_t boot_time = 0;
-  time_t time_now;
-  time_t uptime;
-  intmax_t updays;
-  int uphours;
-  int upmins;
-  struct tm *tmn;
-  double avg[3];
-  int loads;
 
 #if HAVE_SYSCTL && ! defined __GLIBC__ \
 && defined CTL_KERN && defined KERN_BOOTTIME
@@ -81,35 +75,47 @@ print_uptime (idx_t n, struct gl_utmp const *this)
 
   /* Loop through all the utmp entries we just read and count up the valid
  ones, also in the process possibly gleaning boottime. */
-  while (n--)
+  idx_t entries = 0;
+  for (idx_t i = 0; i < n; i++)
 {
+  struct gl_utmp const *this = _buf[i];
   entries += IS_USER_PROCESS (this);
   if (UT_TYPE_BOOT_TIME (this))
 boot_time = this->ut_ts.tv_sec;
-  ++this;
 }
   /* The gnulib module 'readutmp' is supposed to provide a BOOT_TIME entry
  on all platforms.  */
   if (boot_time == 0)
-error (EXIT_FAILURE, errno, _("couldn't get boot time"));
-
-  time_now = time (nullptr);
-  uptime = time_now - boot_time;
-  updays = uptime / 86400;
-  uphours = uptime % 86400 / 3600;
-  upmins = uptime % 86400 % 3600 / 60;
-  tmn = localtime (_now);
+{
+  error (0, errno, _("couldn't get boot time"));
+  status = EXIT_FAILURE;
+}
+
+  time_t time_now = time (nullptr);
+  struct tm *tmn = time_now == (time_t) -1 ? nullptr : localtime (_now);
   /* procps' version of uptime also prints the seconds field, but
  previous versions of coreutils don't. */
   if (tmn)
 /* TRANSLATORS: This prints the current clock time. */
 fprintftime (stdout, _(" %H:%M:%S  "), tmn, 0, 0);
   else
-printf (_(" ??:  "));
-  if (uptime == (time_t) -1)
-printf (_("up  days ??:??,  "));
+{
+  printf (_(" ??:  "));
+  status = EXIT_FAILURE;
+}
+
+  intmax_t uptime;
+  if (time_now == (time_t) -1 || boot_time == 0
+  || ckd_sub (, time_now, boot_time) || uptime < 0)
+{
+  printf (_("up  days ??:??,  "));
+  status = EXIT_FAILURE;
+}
   else
 {
+  intmax_t updays = uptime / 86400;
+  int uphours = uptime % 86400 / 3600;
+  int upmins = uptime % 86400 % 3600 / 60;
   if (0 < updays)
 printf (ngettext ("up %"PRIdMAX" day %2d:%02d,  ",
   "up %"PRIdMAX" days %2d:%02d,  ",
@@ -118,10 +124,12 @@ print_uptime (idx_t n, struct gl_utmp const *this)
   else
 printf (_("up  %2d:%02d,  "), uphours, upmins);
 }
+
   printf (ngettext ("%td user", "%td users", select_plural (entries)),
   entries);
 
-  loads = getloadavg (avg, 3);
+  double avg[3];
+  int loads = getloadavg (avg, 3);
 
   if (loads == -1)
 putchar ('\n');
@@ -136,6 +144,8 @@ print_uptime (idx_t n, struct gl_utmp const *this)
   if (loads > 0)
 putchar ('\n');
 }
+
+  return status;
 }
 
 /* Display the system uptime and the number of users on the system,
@@ -147,12 +157,17 @@ uptime (char const *filename, int options)
 {
   idx_t n_users;
   struct gl_utmp *utmp_buf;
-  if (read_utmp (filename, _users, _buf, options) != 0)
-error (EXIT_FAILURE, errno, "%s", quotef (filename));
-
-  print_uptime (n_users, utmp_buf);
+  int read_utmp_status = (read_utmp (filename, _users, _buf, options) < 0
+  ? EXIT_FAILURE : EXIT_SUCCESS);
+  if (read_utmp_status != EXIT_SUCCESS)
+{
+  error (0, errno, "%s", 

bug#65310: test failure on Alpine Linux: tests/sort/sort-debug-keys

[Pádraig Brady]

On 15/08/2023 14:14, Bruno Haible wrote:

Hi,

Doing "make check" of current coreutils on Alpine Linux 3.18, I see a
test failure that I didn't see with the coreutils-9.3 release:

FAIL: tests/sort/sort-debug-keys

I'm attaching the relevant part of tests/test-suite.log.


In the log we have:

  + LC_ALL=fr_FR.UTF-8 sort --debug -k2g -k1b,1
  sort: text ordering performed using ‘fr_FR.UTF-8’ sorting rules
  sort: note numbers use ‘.’ as a decimal point in this locale

The fact that ',' isn't used as the decimal point is surprising,
and is what's causing the test to fail.
The attached adds an extra guard to the test to skip this portion
if ',' is not in fact the decimal point.

cheers,
PádraigFrom 17e6bcf448890325095cd52d4d9df1b932f27a5a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Tue, 15 Aug 2023 16:44:26 +0100
Subject: [PATCH] tests: fix false failure due to locale on alpine

* tests/sort/sort-debug-keys.sh: Decimal point was seen to be '.'
on fr_FR.UTF-8 on Alpine Linux 3.18, so add an extra guard
to ensure we've a ',' as the decimal point on this locale.
Fixes https://bugs.gnu.org/65310
---
 tests/sort/sort-debug-keys.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/sort/sort-debug-keys.sh b/tests/sort/sort-debug-keys.sh
index c97c64a10..3397ef8f0 100755
--- a/tests/sort/sort-debug-keys.sh
+++ b/tests/sort/sort-debug-keys.sh
@@ -320,6 +320,8 @@ f=$LOCALE_FR_UTF8
 
 : ${LOCALE_FR_UTF8=none}
 if test "$LOCALE_FR_UTF8" != "none"; then
+ LC_NUMERIC=$f LC_MESSAGES=C sort -g --debug /dev/null 2> debug.out
+ if grep 'numbers use .*,.* as a decimal point' debug.out >/dev/null; then
   (
   echo '   1²---++3   1,234  Mi' |
 LC_ALL=C sort --debug -k2g -k1b,1
@@ -331,7 +333,9 @@ if test "$LOCALE_FR_UTF8" != "none"; then
 -k2,2n -k2,2g -k2,2h \
 -k3,3n -k3,3g -k3,3h
   ) | sed 's/^^ .*/^ no match for key/' > out
-  compare exp out || fail=1
+  compare exp out || touch locale_fail
+ fi
+ test -f locale_fail && fail=1
 fi
 
 Exit $fail
-- 
2.41.0

bug#65310: test failure on Alpine Linux: tests/sort/sort-debug-keys

[Bruno Haible]

Hi,

Doing "make check" of current coreutils on Alpine Linux 3.18, I see a
test failure that I didn't see with the coreutils-9.3 release:

FAIL: tests/sort/sort-debug-keys

I'm attaching the relevant part of tests/test-suite.log.

Bruno

==
   GNU coreutils 2023-08-13: ./tests/test-suite.log
==

# TOTAL: 645
# PASS:  431
# SKIP:  211
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/sort/sort-debug-keys


+ initial_cwd_=/home/bruno/coreutils-2023-08-13/build
+ testdir_prefix_
+ printf gt
+ pfx_=gt
+ mktempd_ /home/bruno/coreutils-2023-08-13/build gt-sort-debug-keys.sh.
+ destdir_=/home/bruno/coreutils-2023-08-13/build
+ template_=gt-sort-debug-keys.sh.
+ MAX_TRIES_=4
+ destdir_slash_=/home/bruno/coreutils-2023-08-13/build/
+ unset TMPDIR
+ d=/home/bruno/coreutils-2023-08-13/build/gt-sort-debug-keys.sh.VmIq
+ :
+ test -d /home/bruno/coreutils-2023-08-13/build/gt-sort-debug-keys.sh.VmIq
+ ls -dgo /home/bruno/coreutils-2023-08-13/build/gt-sort-debug-keys.sh.VmIq
+ perms='drwx--S--- 2 4096 Sep 13 08:45 /home/bruno/coreutils-2023-08-13/build/gt-sort-debug-keys.sh.VmIq'
+ :
+ echo /home/bruno/coreutils-2023-08-13/build/gt-sort-debug-keys.sh.VmIq
+ return
+ test_dir_=/home/bruno/coreutils-2023-08-13/build/gt-sort-debug-keys.sh.VmIq
+ cd /home/bruno/coreutils-2023-08-13/build/gt-sort-debug-keys.sh.VmIq
+ srcdir=../..
+ builddir=..
+ export srcdir builddir
+ gl_init_sh_nl_='
'
+ IFS=' 	
'
+ expr 1 + 128
+ eval 'trap '"'"'Exit 129'"'"' 1'
+ trap 'Exit 129' 1
+ expr 2 + 128
+ eval 'trap '"'"'Exit 130'"'"' 2'
+ trap 'Exit 130' 2
+ expr 3 + 128
+ eval 'trap '"'"'Exit 131'"'"' 3'
+ trap 'Exit 131' 3
+ expr 13 + 128
+ eval 'trap '"'"'Exit 141'"'"' 13'
+ trap 'Exit 141' 13
+ expr 15 + 128
+ eval 'trap '"'"'Exit 143'"'"' 15'
+ trap 'Exit 143' 15
+ saved_IFS=' 	
'
+ IFS=:
+ new_PATH=
+ sep_=
+ test -d /home/bruno/coreutils-2023-08-13/build/src/.
+ new_PATH=/home/bruno/coreutils-2023-08-13/build/src
+ sep_=:
+ test -d /home/bruno/bin/.
+ new_PATH=/home/bruno/coreutils-2023-08-13/build/src:/home/bruno/bin
+ sep_=:
+ test -d /usr/local/bin/.
+ new_PATH=/home/bruno/coreutils-2023-08-13/build/src:/home/bruno/bin:/usr/local/bin
+ sep_=:
+ test -d /usr/sbin/.
+ new_PATH=/home/bruno/coreutils-2023-08-13/build/src:/home/bruno/bin:/usr/local/bin:/usr/sbin
+ sep_=:
+ test -d /usr/bin/.
+ new_PATH=/home/bruno/coreutils-2023-08-13/build/src:/home/bruno/bin:/usr/local/bin:/usr/sbin:/usr/bin
+ sep_=:
+ test -d /sbin/.
+ new_PATH=/home/bruno/coreutils-2023-08-13/build/src:/home/bruno/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin
+ sep_=:
+ test -d /bin/.
+ new_PATH=/home/bruno/coreutils-2023-08-13/build/src:/home/bruno/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+ sep_=:
+ IFS=' 	
'
+ PATH=/home/bruno/coreutils-2023-08-13/build/src:/home/bruno/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+ export PATH
+ trap remove_tmp_ EXIT
+ path_prepend_ ./src
+ test 1 '!=' 0
+ path_dir_=./src
+ abs_path_dir_=/home/bruno/coreutils-2023-08-13/build/./src
+ PATH=/home/bruno/coreutils-2023-08-13/build/./src:/home/bruno/coreutils-2023-08-13/build/src:/home/bruno/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+ create_exe_shims_ /home/bruno/coreutils-2023-08-13/build/./src
+ return 0
+ shift
+ test 0 '!=' 0
+ export PATH
+ print_ver_ sort printf
+ require_built_ sort printf
+ skip_=no
+ test no '=' yes
+ test yes '=' yes
+ local i
+ env sort --version
sort (GNU coreutils) 2023-08-13
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and Paul Eggert.
+ env printf --version
printf (GNU coreutils) 2023-08-13
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
+ cat
+ sort -s -k2n --debug
sort: text ordering performed using simple byte comparison
sort: key 1 is numeric and spans multiple fields
sort: note numbers use '.' as a decimal point in this locale
+ printf '1\n\n44\n33\n2\n'
+ sort -s -k1.3n --debug
sort: text ordering performed using simple byte comparison
sort: leading blanks are significant in key 1; consider also specifying 'b'
sort: key 1 is numeric and spans multiple fields
sort: note numbers use '.' as a decimal point in this locale
+ printf '1\n\n44\n33\n2\n'
+ sort -s -k1n --debug
sort: text ordering performed using simple byte comparison
sort: key 1 is numeric and spans multiple fields
sort: note numbers use '.' as a decimal point in this locale
+ printf '1\n\n44\n33\n2\n'
+ sort -s -k2g --debug
sort: text ordering 

bug#65255: uptime's boot time is inconsistent after VM sleep & resume

[Bruno Haible]

I wrote:
> > I'll provide a NEWS
> > entry afterwards, that summarizes the changes in coreutils + gnulib on the
> > various platforms.
> 
Paul Eggert wrote:
> Thanks, this looks good. A NEWS entry would be welcome.

Actually, it's 4 entries:

* The 'uptime' program is now being built on FreeBSD, Haiku.
* 'who -a' now displays the boot time on Alpine Linux, OpenBSD, Cygwin,
   Haiku, and some distributions of Android.
* 'uptime' now succeeds on some distributions of Android.
* The "up" time displayed by 'uptime' now includes VM saved/sleep time on
  Linux, Hurd, GNU/kFreeBSD, NetBSD, OpenBSD, Minix, Cygwin.

Comments:
Re entry 1: Yes, the 'uptime' program was not being built on FreeBSD. A 
consequence
of the fact that FreeBSD has  but no , and of this commit:
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=2984e47c789ebc39f55a3b1cb20b943de88eeedc

Re entry 2, 3: Let's write "some distributions of Android" since for me it works
(under Termux, with an LG Android 11) whereas for Po Lu these two system APIs
don't work (due to SELinux policies).

Re entry 4:
The improvement comes from both
[1] https://lists.gnu.org/archive/html/coreutils/2023-08/msg00028.html
on NetBSD, OpenBSD, Minix,
[2] https://lists.gnu.org/archive/html/bug-coreutils/2023-08/msg00068.html
on Linux, Hurd, GNU/kFreeBSD, NetBSD, Minix, Cygwin.

Find below the detailed test results.

> Does this mean Gnulib's 'uptime' module is obsolete?

It can be marked obsolete, yes. But it should not be removed immediately,
since some other package is using it: dc3dd. See
https://codesearch.debian.net/search?q=uptime+path%3Abootstrap.conf=1

Bruno


TEST RESULTS with
  + current gnulib as of today
  + current coreutils + my patches [1][2]:

Fedora Rawhide Cinnamon

$ date +"%Y-%m-%d %H:%M"
2023-08-15 11:11
$ coreutils-9.3/src/who -a
   system boot  2023-08-09 21:03
   run-level 5  2023-08-09 21:03
bruno+ tty1 2023-08-09 21:03  old 1072 (:0)
   pts/32023-08-15 11:11107603 id=ts/3  term=0 
exit=0
$ coreutils-9.3/src/uptime
 11:11:14  up 5 days 12:57,  1 user,  load average: 0.08, 0.03, 0.00
Includes VM sleep time? no
$ coreutils-2023-08-13/src/who -a
   system boot  2023-08-09 21:03
   run-level 5  2023-08-09 21:03
bruno+ tty1 2023-08-09 21:03  old 1072 (:0)
   pts/32023-08-15 11:11107603 id=ts/3  term=0 
exit=0
$ coreutils-2023-08-13/src/uptime
 11:11:19  up 5 days 14:07,  1 user,  load average: 0.16, 0.04, 0.01
Includes VM sleep time? yes


CentOS 6

$ date +"%Y-%m-%d %H:%M"
2023-08-15 11:18
$ coreutils-9.3/src/who -a
   system boot  2023-08-14 04:45
   run-level 5  2023-08-14 04:45
LOGIN  tty3 2023-08-14 04:45  1889 id=3
LOGIN  tty4 2023-08-14 04:45  1891 id=4
LOGIN  tty2 2023-08-14 04:45  1887 id=2
LOGIN  tty5 2023-08-14 04:45  1893 id=5
LOGIN  tty6 2023-08-14 04:45  1901 id=6
bruno+ tty1 2023-08-14 04:46  old 2072 (:0)
bruno+ pts/02023-08-14 04:46   .  2466 (:0.0)
$ coreutils-9.3/src/uptime
 11:18:14  up 1 day  5:26,  2 users,  load average: 0.00, 0.00, 0.00
Includes VM sleep time? no
$ coreutils-2023-08-13/src/who -a
   system boot  2023-08-14 04:45
   run-level 5  2023-08-14 04:45
LOGIN  tty3 2023-08-14 04:45  1889 id=3
LOGIN  tty4 2023-08-14 04:45  1891 id=4
LOGIN  tty2 2023-08-14 04:45  1887 id=2
LOGIN  tty5 2023-08-14 04:45  1893 id=5
LOGIN  tty6 2023-08-14 04:45  1901 id=6
bruno+ tty1 2023-08-14 04:46  old 2072 (:0)
bruno+ pts/02023-08-14 04:46   .  2466 (:0.0)
$ coreutils-2023-08-13/src/uptime
 11:18:19  up 1 day  6:33,  2 users,  load average: 0.00, 0.00, 0.00
Includes VM sleep time? yes


Raspbian

$ date +"%Y-%m-%d %H:%M"
2023-08-15 11:21
$ coreutils-9.2/src/who -a
   system boot  1970-01-01 01:00
pi   - tty1 2023-07-09 19:16  old  445
pi   + tty7 2023-08-10 14:31  old 7911 (:0)
   run-level 5  2023-08-10 13:07
$ coreutils-9.2/src/uptime
 11:21:36  up 4 days 20:41,  2 users,  load average: 0.69, 0.20, 0.06
Includes VM sleep time? no
$ coreutils-2023-08-13/src/who -a
   system boot  2023-08-10 13:07
pi   - tty1 2023-07-09 19:16  old  445
pi   + tty7 2023-08-10 14:31  old 7911 (:0)
   run-level 5  2023-08-10 13:07
$ coreutils-2023-08-13/src/uptime
 11:21:40  up 4 days 22:13,  2 users,  load average: 

bug#65294: [PATCH] maint: Fix compilation error on GNU/Hurd

[Pádraig Brady]

On 14/08/2023 20:02, Bruno Haible wrote:

Compiling a current coreutils on Debian GNU/Hurd from 2022, I get this
compilation error:

   CC   src/copy.o
../src/copy.c: In function 'set_author':
../src/copy.c:984:15: error: 'MACH_PORT_nullptr' undeclared (first use in this 
function); did you mean 'MACH_PORT_NULL'?
   984 |   if (file == MACH_PORT_nullptr)
   |   ^
   |   MACH_PORT_NULL
../src/copy.c:984:15: note: each undeclared identifier is reported only once 
for each function it appears in
make[2]: *** [Makefile:12489: src/copy.o] Error 1

The attached patch fixes it.



Pushed.

thanks,
Pádraig

bug#65294: [PATCH] maint: Fix compilation error on GNU/Hurd

[Bruno Haible]

Compiling a current coreutils on Debian GNU/Hurd from 2022, I get this
compilation error:

  CC   src/copy.o
../src/copy.c: In function 'set_author':
../src/copy.c:984:15: error: 'MACH_PORT_nullptr' undeclared (first use in this 
function); did you mean 'MACH_PORT_NULL'?
  984 |   if (file == MACH_PORT_nullptr)
  |   ^
  |   MACH_PORT_NULL
../src/copy.c:984:15: note: each undeclared identifier is reported only once 
for each function it appears in
make[2]: *** [Makefile:12489: src/copy.o] Error 1

The attached patch fixes it.

>From 2046827462094dde4ac8391865a3edc74e313126 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Mon, 14 Aug 2023 20:59:41 +0200
Subject: [PATCH] maint: Fix compilation error on GNU/Hurd (regression
 2023-06-29)

* src/copy.c (set_author): Revert change from MACH_PORT_NULL to
MACH_PORT_nullptr.
---
 src/copy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/copy.c b/src/copy.c
index 90eebf6bc..a4aad06a8 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -981,7 +981,7 @@ set_author (char const *dst_name, int dest_desc, const struct stat *src_sb)
   file_t file = (dest_desc < 0
  ? file_name_lookup (dst_name, 0, 0)
  : getdport (dest_desc));
-  if (file == MACH_PORT_nullptr)
+  if (file == MACH_PORT_NULL)
 error (0, errno, _("failed to lookup file %s"), quoteaf (dst_name));
   else
 {
-- 
2.34.1

bug#65276: Build failure with gcc < 4.8

[Pádraig Brady]

On 14/08/2023 00:46, Bruno Haible wrote:

Building the current coreutils on GNU/kFreeBSD 7, I get link errors:

   CCLD src/cksum
src/cksum-cksum.o: In function `pclmul_supported':
/home/bruno/coreutils-2023-08-13/build-64/../src/cksum.c:149: undefined 
reference to `__builtin_cpu_supports'
/home/bruno/coreutils-2023-08-13/build-64/../src/cksum.c:150: undefined 
reference to `__builtin_cpu_supports'
collect2: error: ld returned 1 exit status
make[2]: *** [src/cksum] Error 1
   CCLD src/wc
src/wc.o: In function `avx2_supported':
/home/bruno/coreutils-2023-08-13/build-64/../src/wc.c:150: undefined reference 
to `__builtin_cpu_supports'
collect2: error: ld returned 1 exit status
make[2]: *** [src/wc] Error 1

The reason is that the __builtin_cpu_supports function does not exist
(since the gcc version is 4.7.2 and __builtin_cpu_supports was only
introduced in gcc 4.8), but the configure test succeeds: Compiling this file
=== foo.c ===
#include 

int
main (void)
{
   return __builtin_cpu_supports ("pclmul");
}
=
merely produces warnings:
$ gcc -c -Wall foo.c
foo.c: In function ‘main’:
foo.c:6:3: warning: implicit declaration of function ‘__builtin_cpu_supports’ 
[-Wimplicit-function-declaration]

The attached patch fixes it.



Pushed,

thanks,
Pádraig

bug#65269: Fwd: bug#65269: Possible null pointer dereference on the function cycle_check in rm

[Haoxin Tu]

Just realized I need to send it to this email. Thanks.

-- Forwarded message -
发件人： Haoxin Tu 
Date: 2023年8月14日周一 15:05
Subject: Re: bug#65269: Possible null pointer dereference on the function
cycle_check in rm
To: Paul Eggert 
Cc: <65269-d...@debbugs.gnu.org>


Hi Paul,

Thanks for your quick response.

I have tested the latest git version of coreutils again and it seems the
bug I reported was gone. However, I found another new *invalid-free *issue
which may be induced by the incomplete fix. Please check the bug details
below.

Here is the stack info reported by our tool:
```
Stack:
#06908 in rpl_free () at ../lib/free.c:48
#17133 in free_dir (=93825030210688) at ../lib/fts-cycle.c:159
#26886 in rpl_fts_close (=93825030210688) at ../lib/fts.c:624
#35835 in rm (=93825049567272, =93825049567520) at ../src/remove.c:640
#45469 in __klee_posix_wrapped_main (=2, =93825049567264) at
../src/rm.c:366
#53474 in __user_main (=15, =93825033594992, =93825033595120) at
runtime/POSIX/klee_init_env.c:252
#60686 in __uClibc_main (=15, =93825033594992) at
libc/misc/internals/__uClibc_main.c:401
#70852 in main (=15, =93825033594992)
```
The root cause is that if the function `fts_read` get a return value of
NULL and the malloc from `fts->fts_cycle.state = malloc (sizeof
*fts->fts_cycle.state)` (Line 62 in fts_cycle.c) is NULL, the pointer
`fts->fts_cycle.state` will still keep 0 before the free operation `free
(sp->fts_cycle.state);` (Line 159 in fts_cycle.c), leading to free of
invalid address.

So, I think the fixing in the patch
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f17d397771164c1b0f77fea8fb0abdc99cf4a3e1
did not fully solve the potential issue caused by the improper null pointer
checking from the `fts->fts_cycle.state = malloc (sizeof
*fts->fts_cycle.state)`. Could you please check again and let me know if I
misunderstood anything? Thanks.

Best regards,
Haoxin

Paul Eggert  于2023年8月14日周一 01:29写道：

> On 2023-08-13 02:32, Haoxin Tu wrote:
>
> > We have developed a new tool built on top of KLEE (
> http://klee.github.io/)
> > to
> > automatically test GNU Coreutils-9.0 and found there might be a possible
> > null pointer
> > dereference
>
> Thanks, but this bug was fixed in coreutils 9.2 (2023-03-20), due to
> this patch:
>
>
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f17d397771164c1b0f77fea8fb0abdc99cf4a3e1
>
> I suggest using your tool on the latest release, coreutils 9.3. Or even
> better you can test the coreutils bleeding edge, by executing these
> shell commands, as described in the README-hacking file:
>
>git clone https://git.savannah.gnu.org/git/coreutils.git
>cd coreutils
>./bootstrap
>./configure
>make
>
>

bug#65269: Possible null pointer dereference on the function cycle_check in rm

[Haoxin Tu]

Hi Paul,

Thanks for your quick response.

I have tested the latest git version of coreutils again and it seems the
bug I reported was gone. However, I found another new *invalid-free *issue
which may be induced by the incomplete fix. Please check the bug details
below.

Here is the stack info reported by our tool:
```
Stack:
#06908 in rpl_free () at ../lib/free.c:48
#17133 in free_dir (=93825030210688) at ../lib/fts-cycle.c:159
#26886 in rpl_fts_close (=93825030210688) at ../lib/fts.c:624
#35835 in rm (=93825049567272, =93825049567520) at ../src/remove.c:640
#45469 in __klee_posix_wrapped_main (=2, =93825049567264) at
../src/rm.c:366
#53474 in __user_main (=15, =93825033594992, =93825033595120) at
runtime/POSIX/klee_init_env.c:252
#60686 in __uClibc_main (=15, =93825033594992) at
libc/misc/internals/__uClibc_main.c:401
#70852 in main (=15, =93825033594992)
```
The root cause is that if the function `fts_read` get a return value of
NULL and the malloc from `fts->fts_cycle.state = malloc (sizeof
*fts->fts_cycle.state)` (Line 62 in fts_cycle.c) is NULL, the pointer
`fts->fts_cycle.state` will still keep 0 before the free operation `free
(sp->fts_cycle.state);` (Line 159 in fts_cycle.c), leading to free of
invalid address.

So, I think the fixing in the patch
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f17d397771164c1b0f77fea8fb0abdc99cf4a3e1
did not fully solve the potential issue caused by the improper null pointer
checking from the `fts->fts_cycle.state = malloc (sizeof
*fts->fts_cycle.state)`. Could you please check again and let me know if I
misunderstood anything? Thanks.

Best regards,
Haoxin

Paul Eggert  于2023年8月14日周一 01:29写道：

> On 2023-08-13 02:32, Haoxin Tu wrote:
>
> > We have developed a new tool built on top of KLEE (
> http://klee.github.io/)
> > to
> > automatically test GNU Coreutils-9.0 and found there might be a possible
> > null pointer
> > dereference
>
> Thanks, but this bug was fixed in coreutils 9.2 (2023-03-20), due to
> this patch:
>
>
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f17d397771164c1b0f77fea8fb0abdc99cf4a3e1
>
> I suggest using your tool on the latest release, coreutils 9.3. Or even
> better you can test the coreutils bleeding edge, by executing these
> shell commands, as described in the README-hacking file:
>
>git clone https://git.savannah.gnu.org/git/coreutils.git
>cd coreutils
>./bootstrap
>./configure
>make
>
>

bug#65276: Build failure with gcc < 4.8

[Bruno Haible]

Building the current coreutils on GNU/kFreeBSD 7, I get link errors:

  CCLD src/cksum
src/cksum-cksum.o: In function `pclmul_supported':
/home/bruno/coreutils-2023-08-13/build-64/../src/cksum.c:149: undefined 
reference to `__builtin_cpu_supports'
/home/bruno/coreutils-2023-08-13/build-64/../src/cksum.c:150: undefined 
reference to `__builtin_cpu_supports'
collect2: error: ld returned 1 exit status
make[2]: *** [src/cksum] Error 1
  CCLD src/wc
src/wc.o: In function `avx2_supported':
/home/bruno/coreutils-2023-08-13/build-64/../src/wc.c:150: undefined reference 
to `__builtin_cpu_supports'
collect2: error: ld returned 1 exit status
make[2]: *** [src/wc] Error 1

The reason is that the __builtin_cpu_supports function does not exist
(since the gcc version is 4.7.2 and __builtin_cpu_supports was only
introduced in gcc 4.8), but the configure test succeeds: Compiling this file
=== foo.c ===
#include 

int
main (void)
{
  return __builtin_cpu_supports ("pclmul");
}
=
merely produces warnings:
$ gcc -c -Wall foo.c
foo.c: In function ‘main’:
foo.c:6:3: warning: implicit declaration of function ‘__builtin_cpu_supports’ 
[-Wimplicit-function-declaration]

The attached patch fixes it.

>From a57d40e3f6997845ce88be6f40813b1b26cb6e16 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Mon, 14 Aug 2023 01:45:39 +0200
Subject: [PATCH] cksum,wc: Fix link errors with gcc < 4.8

* configure.ac: Attempt to link, not only compile, the test programs
with __builtin_cpu_supports.
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 786ce81a5..5e5a55dab 100644
--- a/configure.ac
+++ b/configure.ac
@@ -519,7 +519,7 @@ ac_c_werror_flag=$cu_save_c_werror_flag
 ac_save_CFLAGS=$CFLAGS
 CFLAGS="-mavx -mpclmul $CFLAGS"
 AC_MSG_CHECKING([if pclmul intrinsic exists])
-AC_COMPILE_IFELSE(
+AC_LINK_IFELSE(
   [AC_LANG_SOURCE([[
 #include 
 
@@ -548,7 +548,7 @@ CFLAGS=$ac_save_CFLAGS
 
 CFLAGS="-mavx2 $CFLAGS"
 AC_MSG_CHECKING([if avx2 intrinstics exists])
-AC_COMPILE_IFELSE(
+AC_LINK_IFELSE(
   [AC_LANG_SOURCE([[
 #include 
 
-- 
2.34.1

bug#65269: Possible null pointer dereference on the function cycle_check in rm

[Paul Eggert]

On 2023-08-13 02:32, Haoxin Tu wrote:


We have developed a new tool built on top of KLEE (http://klee.github.io/)
to
automatically test GNU Coreutils-9.0 and found there might be a possible
null pointer
dereference


Thanks, but this bug was fixed in coreutils 9.2 (2023-03-20), due to 
this patch:


https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f17d397771164c1b0f77fea8fb0abdc99cf4a3e1

I suggest using your tool on the latest release, coreutils 9.3. Or even 
better you can test the coreutils bleeding edge, by executing these 
shell commands, as described in the README-hacking file:


  git clone https://git.savannah.gnu.org/git/coreutils.git
  cd coreutils
  ./bootstrap
  ./configure
  make

bug#65269: Possible null pointer dereference on the function cycle_check in rm

[Haoxin Tu]

Hi,

We have developed a new tool built on top of KLEE (http://klee.github.io/)
to
automatically test GNU Coreutils-9.0 and found there might be a possible
null pointer
dereference in the function cycle_check in cycle_check.c:60 in the util
`rm`. Here is the stack info when the error occurs:

Stack:
#11692 in cycle_check (state, sb) at ../lib/cycle-check.c:60
#100011557 in enter_dir (fts=93825010233600, ent) at ../lib/fts-cycle.c:108
#26327 in rpl_fts_read (sp=93825010233600) at ../lib/fts.c:1024
#35804 in rm (file=93825049838472, x=93825049351680) at
../src/remove.c:597
#45484 in __klee_posix_wrapped_main (argc=2, argv=93825049838464) at
../src/rm.c:370
#53487 in __user_main (=15, =93825010487520, =93825010487648) at
runtime/POSIX/klee_init_env.c:252
#60685 in __uClibc_main (=15, =93825010487520) at
libc/misc/internals/__uClibc_main.c:401
#70851 in main (=15, =93825010487520)

The root cause of the error may lie in the following code:
```
static bool setup_dir (FTS *fts) {
  fts->fts_cycle.state = malloc (sizeof *fts->fts_cycle.state);
  if (! fts->fts_cycle.state)
return false;
  cycle_check_init (fts->fts_cycle.state);
}
```
Specifically, the error occurs when the while-loop in function `rm`
executes the second time and the allocation in the above function
`setup_dir` returns false the first time. When the false value is returned,
the function `cycle_check_init` is not executed, so the object
`fts->fts_cycle.state` is not initialized. However, the
`fts->fts_cycle.state` with the value NULL is used later in the function
`cycle_check` in `assure (state->magic == CC_MAGIC);`. The dereferencing of
the pointer `state->magic` leads to the potential null pointer dereference
issue.

We only tested the Coreutil-9.0 version but the latest versions may have
the same potential issue after we checked the code.  Can you please take a
look and check if this is a valid issue or not?

Adding a simple checking of the pointer `state->magic` before invoking
the function `assure` or changing the timing to call the function
`cycle_check_init` should avoid the potential issue if it is indeed an
error. Thanks.


Best,
Haoxin

bug#65255: uptime's boot time is inconsistent after VM sleep & resume

[Paul Eggert]

On 2023-08-12 16:00, Bruno Haible wrote:


I see this as a bug. Find attached a fix for this bug. I'll provide a NEWS
entry afterwards, that summarizes the changes in coreutils + gnulib on the
various platforms.


Thanks, this looks good. A NEWS entry would be welcome.

Does this mean Gnulib's 'uptime' module is obsolete?

bug#65255: uptime's boot time is inconsistent after VM sleep & resume

[Bruno Haible]

PS: I wrote:
> (print_uptime): Don't read /proc/uptime

You might wonder: What is the replacement? Namely, as a fallback (for
situations where the current process is running inside a container or jail):
  - On Linux, the auxiliary function get_linux_boot_time_final_fallback
reads the info from /proc/uptime.
  - On macOS and BSD systems, we don't need to read it, because the sysctl
invoked by the auxiliary function get_bsd_boot_time_final_fallback
reads the same info, without needing a mounted /proc file system.
  - On Minix and Cygwin, no replacement is needed, because there is no
"container" or "jail" concept in these OSes.

Bruno

bug#65255: uptime's boot time is inconsistent after VM sleep & resume

[Bruno Haible]

On the following platforms:
  - Linux (that includes glibc-based systems, Alpine Linux, Raspbian),
  - NetBSD,
  - Cygwin,
  - Minix,

the "up" duration is inconsistent after the VM in which the OS is running
has been
  1. put into sleep / saved / pause mode (terminology depends on the
 hypervisor),
  2. resumed,
  3. a date bump has been done in the VM (either automatically or manually).

VM sleep and a date adjustment after resume is a common operation, as can
be seen
  - from the fact that it's automatic in VirtualBox machines with the
"guest extensions" installed [1],
  - from the fact that it's automatic in KVM [2],
  - from the fact that it's automatic in Haiku as guest,
  - from a remark in the libvirt documentation [3],
  - from stackoverflow questions such as [4].

After such a VM sleep and a date adjustment, coreutils' "uptime" is
inconsistent in three ways:

  * On Linux, the displayed "up" duration includes active time and
hardware suspend time [5], but excludes VM sleep time.

Such a figure is not useful for estimating the boot time, since
(time now) - (that "up" time) is not the boot time.

It is also not useful for estimating when e.g. a file system check
would be necessary on file systems without a journal, or how much
electricity was consumed — since the hardware suspend time was included.

So this figure is useless.

  * The displayed "up" duration is inconsistent with the boot time displayed
by "who -a". (Since the Gnulib module 'readutmp' makes efforts to find
the boot time in a way that does not change when the date is adjusted.)

  * The behaviour is inconsistent among platforms: On platforms which have
a /proc/uptime file, the displayed "up" time _excludes_ VM sleep time.
On the other platforms it _includes_ VM sleep time.

Seen on Linux (Fedora Rawhide, Alpine Linux 3.18, Raspbian), NetBSD 9.3,
Cygwin 2.9.0, Minix 3.3.

I see this as a bug. Find attached a fix for this bug. I'll provide a NEWS
entry afterwards, that summarizes the changes in coreutils + gnulib on the
various platforms.

Bruno


[1] 
https://docs.oracle.com/en/virtualization/virtualbox/6.1/user/guestadditions.html#4.1.-Introduction-to-Guest-Additions
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1115340
[3] 
https://libvirt.gitlab.io/libvirt-appdev-guide-python/libvirt_application_development_guide_using_python-Guest_Domains-Lifecycle-Save.html
[4] https://serverfault.com/questions/334698/
[5] This is indicated by glibc's :
  /* Monotonic system-wide clock that includes time spent in suspension.  */
  # define CLOCK_BOOTTIME 7
I also verified this on a laptop.
>From ff6e92f38b560ade54df4c94e9d91657f740bb4b Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Sun, 13 Aug 2023 00:57:23 +0200
Subject: [PATCH] uptime: Include VM sleep time in the "up" duration

* src/uptime.c: Don't include c-strtod.h.
(print_uptime): Don't read /proc/uptime, because the value it provides
does not change when a date adjustment occurs.
* bootstrap.conf (gnulib_modules): Remove 'uptime'.
---
 bootstrap.conf |  1 -
 src/uptime.c   | 36 ++--
 2 files changed, 6 insertions(+), 31 deletions(-)

diff --git a/bootstrap.conf b/bootstrap.conf
index 6ce27d5dd..d758a9ff6 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -285,7 +285,6 @@ gnulib_modules="
   unlocked-io
   unsetenv
   update-copyright
-  uptime
   useless-if-before-free
   userspec
   utimecmp
diff --git a/src/uptime.c b/src/uptime.c
index c29798d32..0cc1dedba 100644
--- a/src/uptime.c
+++ b/src/uptime.c
@@ -22,7 +22,6 @@
 #include 
 #include "system.h"
 
-#include "c-strtod.h"
 #include "long-options.h"
 #include "quote.h"
 #include "readutmp.h"
@@ -42,33 +41,13 @@ print_uptime (idx_t n, struct gl_utmp const *this)
   idx_t entries = 0;
   time_t boot_time = 0;
   time_t time_now;
-  time_t uptime = 0;
+  time_t uptime;
   intmax_t updays;
   int uphours;
   int upmins;
   struct tm *tmn;
   double avg[3];
   int loads;
-#ifdef HAVE_PROC_UPTIME
-  FILE *fp;
-
-  fp = fopen ("/proc/uptime", "r");
-  if (fp != nullptr)
-{
-  char buf[BUFSIZ];
-  char *b = fgets (buf, BUFSIZ, fp);
-  if (b == buf)
-{
-  char *end_ptr;
-  double upsecs = c_strtod (buf, _ptr);
-  if (buf != end_ptr)
-uptime = (0 <= upsecs && upsecs < TYPE_MAXIMUM (time_t)
-  ? upsecs : -1);
-}
-
-  fclose (fp);
-}
-#endif /* HAVE_PROC_UPTIME */
 
   /* Loop through all the utmp entries we just read and count up the valid
  ones, also in the process possibly gleaning boottime. */
@@ -79,16 +58,13 @@ print_uptime (idx_t n, struct gl_utmp const *this)
 boot_time = this->ut_ts.tv_sec;
   ++this;
 }
+  /* The gnulib module 'readutmp' is supposed to provide a BOOT_TIME entry
+ on all platforms.  */
+  if (boot_time == 0)
+error (EXIT_FAILURE, errno, _("couldn't get boot time"));
 
   time_now 

bug#64937: boot time on Linux

[Po Lu via GNU coreutils Bug Reports]

Bruno Haible  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:
> 
> 
>
> 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#64937: boot time on Linux

[Bruno Haible]

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  

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 = [i];
   if (UT_TYPE_BOOT_TIME (ut))
 {
+  /* Workaround for Raspbian:  */
+  if (ut->ut_ts.tv_sec <= 60 && runlevel_ts.tv_sec != 0)
+ 

bug#64937: boot time on Linux

[Bruno Haible]

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:



Maybe one of these makes the difference?

Bruno

bug#64937: boot time on Linux

[Natanael Copa]

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  wrote:

> [For those cc'ed, the thread's at .]
>
> 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

bug#64937: boot time on Linux

[Po Lu via GNU coreutils Bug Reports]

Bruno Haible  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.

bug#64937: "who" reports funny dates

[Thorsten Kukuk via GNU coreutils Bug Reports]

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)

bug#64937: "who" reports funny dates

[Bruno Haible]

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=
  $ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR

Bruno

bug#64937: boot time on Linux

[Bruno Haible]

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

bug#64937: boot time on Linux

[Po Lu via GNU coreutils Bug Reports]

Bruno Haible  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.

bug#64937: "who" reports funny dates

[Thorsten Kukuk via GNU coreutils Bug Reports]

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  
> 
>   readutmp: Get the boot time with higher precision.
>   Suggested by Thorsten Kukuk  in
>   
> .
>   * 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)

bug#64937: boot time on Linux

[Bruno Haible]

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
From 9db6a91083ecca9c49bd5353c7624c6388f332fb Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Thu, 10 Aug 2023 07:59:19 +0200
Subject: [PATCH] readutmp: Return a boot time also on Android.

* lib/readutmp.c (get_linux_uptime): New function, extracted from
get_boot_time_uncached.
(read_utmp_from_file): Don't look for file time stamps on Android.
Instead, use get_linux_uptime.
(get_boot_time_uncached): Use get_linux_uptime.
---
 ChangeLog  |   9 +++
 lib/readutmp.c | 196 +
 2 files changed, 124 insertions(+), 81 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 3c2256a7b2..b167189c03 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2023-08-10  Bruno Haible  
+
+	readutmp: Return a boot time also on Android.
+	* lib/readutmp.c (get_linux_uptime): New function, extracted from
+	get_boot_time_uncached.
+	(read_utmp_from_file): Don't look for file time stamps on Android.
+	Instead, use get_linux_uptime.
+	(get_boot_time_uncached): Use get_linux_uptime.
+
 2023-08-09  Bruno Haible  
 
 	readutmp: Fix a mistake (regression 2023-08-08).
diff --git a/lib/readutmp.c b/lib/readutmp.c
index ec21f5e16f..b344d8294d 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -31,11 +31,13 @@
 #include 
 #include 
 
+#if READUTMP_USE_SYSTEMD || defined __ANDROID__
+# include 
+# include 
+#endif
 #if READUTMP_USE_SYSTEMD
 # include 
-# include 
 # include 
-# include 
 #endif
 
 #include "stat-time.h"
@@ -284,6 +286,60 @@ finish_utmp (struct utmp_alloc a)
   return a;
 }
 
+# if READUTMP_USE_SYSTEMD || defined __ANDROID__
+
+/* Store the uptime counter, as managed by the Linux kernel, in *P_UPTIME.
+   Return 0 upon success, -1 upon failure.  */
+static int
+get_linux_uptime (struct timespec *p_uptime)
+{
+  /* 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) || defined __ANDROID__
+  if (clock_gettime (CLOCK_BOOTTIME, p_uptime) >= 0)
+return 0;
+#  endif
+
+  /* /proc/uptime contains the uptime with a resolution of 0.01 sec.
+ But it does not have read permissions on Android.  */
+#  if !defined __ANDROID__
+  FILE *fp = fopen ("/proc/uptime", "re");
+  if (fp != NULL)
+{
+  char buf[32 + 1];
+  size_t n = fread (buf, 1, sizeof (buf) - 1, fp);
+  fclose (fp);
+  if (n > 0)
+{
+  buf[n] = '\0';
+  /* buf now contains two values: the uptime and the idle time.  */
+  char *endptr;
+  double uptime = strtod (buf, );
+  if (endptr > buf)
+{
+  p_uptime->tv_sec = (time_t) uptime;
+  p_uptime->tv_nsec = (uptime - p_uptime->tv_sec) * 1e9 + 0.5;
+  return 0;
+}
+}
+}
+#  endif
+
+  /* The sysinfo call returns the uptime with a resolution of 1 sec only.  */
+  struct sysinfo info;
+  if (sysinfo () >= 0)
+{
+  p_uptime->tv_sec = info.uptime;
+  p_uptime->tv_nsec = 0;
+  return 0;
+}
+
+  return -1;
+}
+
+# endif
+
 # if !HAVE_UTMPX_H && HAVE_UTMP_H && defined UTMP_NAME_FUNCTION && !HAVE_DECL_GETUTENT
 struct utmp *getutent (void);
 # endif
@@ -391,7 +447,7 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
 
   END_UTMP_ENT ();
 
-#  if defined __linux__
+#  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.  */
@@ -436,6 +492,37 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
 }
 #  endif
 
+#  if defined __ANDROID__
+  /* On Android, there is no /var, and normal processes don't have access
+ to system files.  Therefore use the kernel's uptime counter, although
+ it produces wrong values after the date has been bumped in the running
+ system.  */
+  {

bug#64937: boot time on Linux

[Natanael Copa]

On Thu, 10 Aug 2023 17:38:10 +0800
Po Lu  wrote:

> Natanael Copa  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

bug#64937: boot time on Linux

[Po Lu via GNU coreutils Bug Reports]

Natanael Copa  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?

bug#64937: boot time on Linux

[Po Lu via GNU coreutils Bug Reports]

Paul Eggert  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.

bug#64937: boot time on Linux

[Paul Eggert]

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.

bug#64937: boot time on Linux

[Po Lu via GNU coreutils Bug Reports]

Bruno Haible  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.

bug#64937: boot time on Linux

[Bruno Haible]

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
#include 
#include 
#include 
#include 
#include 

static const char *
as_time_string (time_t tim)
{
  struct tm *gmt = gmtime ();
  static char timbuf[100];
  if (gmt == NULL
  || strftime (timbuf, sizeof (timbuf), "%Y-%m-%d %H:%M:%S", gmt)
 == 0)
strcpy (timbuf, "---");
  return timbuf;
}

int main ()
{
  /* clock() returns the uptime with a resolution of ca. 1 usec.  */
  struct timespec ts_now;
  struct timespec up;
  if (clock_gettime (CLOCK_REALTIME, _now) == 0
  && clock_gettime (CLOCK_BOOTTIME, ) == 0)
{
  struct timespec result = ts_now;

  if (result.tv_nsec < up.tv_nsec)
{
  result.tv_nsec += 10;
  result.tv_sec -= 1;
}
  result.tv_sec -= up.tv_sec;
  result.tv_nsec -= up.tv_nsec;
  printf ("from clock  : %d.%09d = %s.%09d\n",
  (int) result.tv_sec, (int) result.tv_nsec,
  as_time_string (result.tv_sec), (int) result.tv_nsec);
}

  /* /proc/uptime contains the uptime with a resolution of 0.01 sec.  */
  FILE *fp = fopen ("/proc/uptime", "re");
  if (fp != NULL)
{
  char buf[32 + 1];
  size_t n = fread (buf, 1, sizeof (buf) - 1, fp);
  fclose (fp);
  if (n > 0)
{
  buf[n] = '\0';
  /* buf now contains two values: the uptime and the idle time.  */
  char *endptr;
  double uptime = strtod (buf, );
  if (endptr > buf)
{
  struct timespec result;
  if (clock_gettime (CLOCK_REALTIME, ) == 0)
{
  time_t uptime_sec = uptime;
  struct timespec up =
{
  .tv_sec = uptime_sec,
  .tv_nsec = (uptime - uptime_sec) * 1e9 + 0.5
};
  if (result.tv_nsec < up.tv_nsec)
{
  result.tv_nsec += 10;
  result.tv_sec -= 1;
}
  result.tv_sec -= up.tv_sec;
  result.tv_nsec -= up.tv_nsec;
  printf ("from /proc  : %d.%09d = %s.%09d\n",
  (int) result.tv_sec, (int) result.tv_nsec,
  as_time_string (result.tv_sec), (int) result.tv_nsec);
}
}
}
}

  /* The sysinfo call returns the uptime with a resolution of 1 sec only.  */
  struct sysinfo info;
  if (sysinfo () >= 0)
{
  struct timespec result;
  if (clock_gettime (CLOCK_REALTIME, ) == 0)
{
  result.tv_sec -= info.uptime;
  printf ("from sysinfo: %d.%09d = %s.%09d\n",
  (int) result.tv_sec, (int) result.tv_nsec,
  as_time_string (result.tv_sec), (int) result.tv_nsec);
}
}

  return 0;
}

bug#64937: boot time on Linux

[Po Lu via GNU coreutils Bug Reports]

Paul Eggert  writes:

> [For those cc'ed, the thread's at .]
>
> 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.

bug#64937: boot time on Linux

[Bruno Haible]

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

bug#64937: boot time on Linux

[Bruno Haible]

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  

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.

From 1e4bc08eb8ce3c00f7b8e72dc69e07ccbc63ed20 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Wed, 9 Aug 2023 18:49:22 +0200
Subject: [PATCH 1/4] 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.
---
 ChangeLog  |  12 ++-
 lib/readutmp.c | 245 +++--
 lib/readutmp.h |  12 ++-
 3 files changed, 157 insertions(+), 112 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 40274c0a08..c2c9613643 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,7 +1,17 @@
+2023-08-09  Bruno Haible  
+
+	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.
+
 2023-08-08  Paul Eggert  
 
 	readutmp: omit pragma
-	* lib/readutmp.c: Omit -Sstringop-overread pragma.
+	* lib/readutmp.c: Omit -Wstringop-overread pragma.
 	It’s no longer needed now that extract_trimmed_name
 	no longer calls strnlen.
 
diff --git a/lib/readutmp.c b/lib/readutmp.c
index 31db4023a1..a7773c4f36 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -163,6 +163,13 @@ desirable_utmp_entry (STRUCT_UTMP const *ut, int options)
   && ut->ut_line[0] == '\0' && ut->ut_host[0] == '\0')
 return false;
 # endif
+
+  bool boot_time = UT_TYPE_BOOT_TIME (ut);
+  if ((options & READ_UTMP_BOOT_TIME) && !boot_time)
+return false;
+  if ((options & READ_UTMP_NO_BOOT_TIME) && boot_time)
+return false;
+
   bool user_proc = IS_USER_PROCESS (ut);
   if ((options & READ_UTMP_USER_PROCESS) && !user_proc)
 return false;
@@ -171,6 +178,7 @@ desirable_utmp_entry (STRUCT_UTMP const *ut, int options)
   && 0 < UT_PID (ut)
   && (kill (UT_PID (ut), 0) < 0 && errno == ESRCH))
 return false;
+
   return true;
 }
 
@@ -441,7 +449,7 @@ read_utmp_from_systemd (idx_t *n_entries, STRUCT_UTMP **utmp_buf, int options)
   struct utmp_alloc a = {0};
 
   /* Synthesize a BOOT_TIME entry.  */
-  if (!(options & READ_UTMP_USER_PROCESS))
+  if (!(options & (READ_UTMP_USER_PROCESS | READ_UTMP_NO_BOOT_TIME)))
 a = add_utmp (a, options,
   

bug#64937: boot time on Linux

[Paul Eggert]

[For those cc'ed, the thread's at .]

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.From cc0a30a876adffa5ec110df9f4e0f21097f6d73e Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Wed, 9 Aug 2023 12:06:25 -0700
Subject: [PATCH] Adjust to random-seed move

For some time, GNU/Linux systems have put their random-seed file
somewhere other than where src/filelock.c looks for it.
Catch up to this by having 'configure' scout for it.
* configure.ac (BOOT_TIME_FILE):
Define this at configure-time.
* nt/inc/ms-w32.h (BOOT_TIME_FILE): Override 'configure'.
* src/filelock.c (BOOT_TIME_FILE): Remove default definition,
since 'configure' defaults it now.
---
 configure.ac| 31 +++
 nt/inc/ms-w32.h |  1 +
 src/filelock.c  |  6 --
 3 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 6e080c1c666..56c8cf1ae05 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2625,6 +2625,37 @@ AC_DEFUN
 fi
 AC_SUBST([AUTO_DEPEND])
 
+AC_CACHE_CHECK([for old but post-boot file],
+  [emacs_cv_boot_time_file],
+  [AS_CASE([$opsys],
+ [*bsd|darwin|dragonfly],
+   [emacs_cv_boot_time_file='not needed'],
+ [emacs_cv_boot_time_file=unknown
+  AS_IF([test $cross_compiling = no],
+	[# systemd puts it in /var/lib/systemd.
+	 # initscripts puts it in /var/lib/urandom (previously /var/lib).
+	 # Linux drivers/char/random.c before 2022-02-21 suggests /var/run.
+	 for file in \
+	 /var/lib/systemd/random-seed \
+	 /var/lib/urandom/random-seed \
+	 /var/lib/random-seed \
+	 /var/run/random-seed
+	 do
+	   test -f $file && { emacs_cv_boot_time_file=$file; break; }
+	 done])])])
+AS_CASE([$emacs_cv_boot_time_file],
+  [/*|*:*], [BOOT_TIME_FILE=\"$emacs_cv_boot_time_file\"],
+  [NULL|nullptr|0], [BOOT_TIME_FILE=$emacs_cv_boot_time_file],
+  ['not needed'], [BOOT_TIME_FILE=NULL],
+  [# Guess systemd if unknown.
+   # If guess is wrong, Emacs falls back on something else.
+   BOOT_TIME_FILE=\"/var/lib/systemd/random-seed\"])
+AC_DEFINE_UNQUOTED([BOOT_TIME_FILE], [$BOOT_TIME_FILE],
+  [Name of file that, if it exists, postdates boot and predates
+   the first Emacs invocation; or a null pointer if no such file is known.
+   This file is used only on GNU/Linux and other systems
+   that lack the FreeBSD-style sysctl with KERN_BOOTTIME.])
+
  Choose a window system.
 
 ## We leave window_system equal to none if
diff --git a/nt/inc/ms-w32.h b/nt/inc/ms-w32.h
index 58be1199345..b23fd5030fa 100644
--- a/nt/inc/ms-w32.h
+++ b/nt/inc/ms-w32.h
@@ -121,6 +121,7 @@ #define HAVE_C99_STRTOLD 1
the output, but that's gross.  So this should do; if the file is
not there, the boot time will be returned as zero, and filelock.c
already handles that.  */
+#undef BOOT_TIME_FILE
 #define BOOT_TIME_FILE "C:/pagefile.sys"
 
 /*  */
diff --git a/src/filelock.c b/src/filelock.c
index 66b8fd2ceac..0ad130353f3 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -59,12 +59,6 @@ Copyright (C) 1985-1987, 1993-1994, 1996, 1998-2023 Free Software
 #include 
 #endif
 
-/* A file whose last-modified time is just after the most recent boot.
-   Define this to be NULL to disable checking for this file.  */
-#ifndef BOOT_TIME_FILE
-#define BOOT_TIME_FILE "/var/run/random-seed"
-#endif
-
 /* Boot time is not available on Android.  */
 
 #if defined HAVE_ANDROID && !defined ANDROID_STUBIFY
-- 
2.39.2

bug#64937: boot time on Linux

[Bruno Haible]

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

bug#64937: "who" reports funny dates

[Paul Eggert]

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.From e14d7e198f96039dbc4fb2118739e6ca1fc4cec6 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 8 Aug 2023 19:29:55 -0700
Subject: [PATCH] readutmp: omit pragma
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lib/readutmp.c: Omit -Sstringop-overread pragma.
It’s no longer needed now that extract_trimmed_name
no longer calls strnlen.
---
 ChangeLog  | 7 +++
 lib/readutmp.c | 5 -
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 199c818c18..40274c0a08 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2023-08-08  Paul Eggert  
+
+	readutmp: omit pragma
+	* lib/readutmp.c: Omit -Sstringop-overread pragma.
+	It’s no longer needed now that extract_trimmed_name
+	no longer calls strnlen.
+
 2023-08-08  Bruno Haible  
 
 	readutmp: Use classical implementation for files != /var/run/utmp.
diff --git a/lib/readutmp.c b/lib/readutmp.c
index 66b25bc7ae..31db4023a1 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -136,11 +136,6 @@
 # pragma GCC diagnostic ignored "-Wsizeof-pointer-memaccess"
 #endif
 
-/* Work around .  */
-#if 11 <= __GNUC__
-# pragma GCC diagnostic ignored "-Wstringop-overread"
-#endif
-
 /* Copy UT->ut_user into storage obtained from malloc.  Then remove any
trailing spaces from the copy, NUL terminate it, and return the copy.  */
 
-- 
2.39.2

From 422dcd424ca6b5fbef8d3bd0088e8e9e3757a203 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 8 Aug 2023 19:32:49 -0700
Subject: [PATCH 1/2] pinky,who: omit pragma

* src/pinky.c, src/who.c:
Omit no-longer-needed -Wstringop-overread pragma.
---
 src/pinky.c | 6 --
 src/who.c   | 6 --
 2 files changed, 12 deletions(-)

diff --git a/src/pinky.c b/src/pinky.c
index 1429dd073..59c552bf1 100644
--- a/src/pinky.c
+++ b/src/pinky.c
@@ -426,12 +426,6 @@ print_heading (void)
   putchar ('\n');
 }
 
-/* Work around ,
-   triggered by STREQ_LEN with a negative length.  */
-#if 11 <= __GNUC__
-# pragma GCC diagnostic ignored "-Wstringop-overread"
-#endif
-
 /* Display UTMP_BUF, which should have N entries. */
 
 static void
diff --git a/src/who.c b/src/who.c
index 27a7904e1..074d2d5ad 100644
--- a/src/who.c
+++ b/src/who.c
@@ -570,12 +570,6 @@ print_heading (void)
   _("PID"), _("COMMENT"), _("EXIT"));
 }
 
-/* Work around ,
-   triggered by STREQ_LEN with a negative length.  */
-#if 11 <= __GNUC__
-# pragma GCC diagnostic ignored "-Wstringop-overread"
-#endif
-
 /* Display UTMP_BUF, which should have N entries. */
 static void
 scan_entries (idx_t n, const STRUCT_UTMP *utmp_buf)
-- 
2.39.2

From ad823360267cbfb3f5b1b3e1438122e5c82eb0b2 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 8 Aug 2023 20:03:40 -0700
Subject: [PATCH 2/2] who: simplify based on readutmp changes

* src/pinky.c (time_string, print_entry, scan_entries, short_pinky):
* src/uptime.c (print_uptime, uptime):
* src/users.c (list_entries_users, users):
* src/who.c (UT_TYPE_RUN_LVL, UT_TYPE_INIT_PROCESS)
(UT_TYPE_LOGIN_PROCESS, UT_TYPE_DEAD_PROCESS, UT_TYPE_NEW_TIME)
(time_string, print_user, print_boottime)
(make_id_equals_comment, print_deadprocs, print_login)
(print_initspawn, print_clockchange, print_runlevel)
(list_entries_who, scan_entries, who):
Simplify, partly by using plain -> rather than macros.
---
 src/pinky.c  | 33 ++-
 src/uptime.c |  7 +++---
 src/users.c  |  5 ++---
 src/who.c| 63 ++--
 4 files changed, 44 insertions(+), 64 deletions(-)

diff --git a/src/pinky.c b/src/pinky.c
index 59c552bf1..5ad05e553 100644
--- a/src/pinky.c
+++ b/src/pinky.c
@@ -172,18 +172,10 @@ idle_string (time_t when)
 
 /* Return a time string.  */
 static char const *
-time_string (const STRUCT_UTMP *utmp_ent)
+time_string (struct gl_utmp const *utmp_ent)
 {
   static char buf[INT_STRLEN_BOUND (intmax_t) + sizeof "-%m-%d %H:%M"];
-
-  /* Don't take the address of UT_TIME_MEMBER directly.
- Ulrich Drepper wrote:
- "... GNU libc (and perhaps other libcs as well) have extended
- utmp file formats which do not use a simple time_t ut_time field.
- In glibc, ut_time is a macro which selects for backward compatibility
- the tv_sec member of a struct timeval value."  */
-  time_t t = UT_TIME_MEMBER (utmp_ent);
-  struct tm *tmp = localtime ();
+  struct tm *tmp = localtime (_ent->ut_ts.tv_sec);
 
   if (tmp)
 {
@@ -191,13 +183,13 @@ time_string (const STRUCT_UTMP *utmp_ent)
   return buf;
 }
   else
-return timetostr (t, buf);
+return timetostr (utmp_ent->ut_ts.tv_sec, buf);
 }
 
 /* Display a line 

bug#65167: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 5.10-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/speculation: Add force option to GDS mitigation

to the 5.10-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-speculation-add-force-option-to-gds-mitigation.patch
and it can be found in the queue-5.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From a0dd9af7b73965177a30e3f14a70452029e06e28 Mon Sep 17 00:00:00 2001
From: Daniel Sneddon 
Date: Wed, 12 Jul 2023 19:43:12 -0700
Subject: x86/speculation: Add force option to GDS mitigation

From: Daniel Sneddon 

commit 553a5c03e90a6087e88f8ff878335ef0621536fb upstream

The Gather Data Sampling (GDS) vulnerability allows malicious software
to infer stale data previously stored in vector registers. This may
include sensitive data such as cryptographic keys. GDS is mitigated in
microcode, and systems with up-to-date microcode are protected by
default. However, any affected system that is running with older
microcode will still be vulnerable to GDS attacks.

Since the gather instructions used by the attacker are part of the
AVX2 and AVX512 extensions, disabling these extensions prevents gather
instructions from being executed, thereby mitigating the system from
GDS. Disabling AVX2 is sufficient, but we don't have the granularity
to do this. The XCR0[2] disables AVX, with no option to just disable
AVX2.

Add a kernel parameter gather_data_sampling=force that will enable the
microcode mitigation if available, otherwise it will disable AVX on
affected systems.

This option will be ignored if cmdline mitigations=off.

This is a *big* hammer.  It is known to break buggy userspace that
uses incomplete, buggy AVX enumeration.  Unfortunately, such userspace
does exist in the wild:

https://www.mail-archive.com/bug-coreutils@gnu.org/msg33046.html

[ dhansen: add some more ominous warnings about disabling AVX ]

Signed-off-by: Daniel Sneddon 
Signed-off-by: Dave Hansen 
Acked-by: Josh Poimboeuf 
Signed-off-by: Daniel Sneddon 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/admin-guide/hw-vuln/gather_data_sampling.rst |   18 +--
 Documentation/admin-guide/kernel-parameters.txt|8 -
 arch/x86/kernel/cpu/bugs.c |   20 -
 3 files changed, 40 insertions(+), 6 deletions(-)

--- a/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
+++ b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
@@ -60,14 +60,21 @@ bits:
     ===   
 
 GDS can also be mitigated on systems that don't have updated microcode by
-disabling AVX. This can be done by setting "clearcpuid=avx" on the kernel
-command-line.
+disabling AVX. This can be done by setting gather_data_sampling="force" or
+"clearcpuid=avx" on the kernel command-line.
+
+If used, these options will disable AVX use by turning on XSAVE YMM support.
+However, the processor will still enumerate AVX support.  Userspace that
+does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
+support will break.
 
 Mitigation control on the kernel command line
 -
 The mitigation can be disabled by setting "gather_data_sampling=off" or
-"mitigations=off" on the kernel command line. Not specifying either will
-default to the mitigation being enabled.
+"mitigations=off" on the kernel command line. Not specifying either will 
default
+to the mitigation being enabled. Specifying "gather_data_sampling=force" will
+use the microcode mitigation when available or disable AVX on affected systems
+where the microcode hasn't been updated to include the mitigation.
 
 GDS System Information
 
@@ -83,6 +90,9 @@ The possible values contained in this fi
  Vulnerable Processor vulnerable and mitigation disabled.
  Vulnerable: No microcode   Processor vulnerable and microcode is missing
 mitigation.
+ Mitigation: AVX disabled,
+ no microcode   Processor is vulnerable and microcode is 
missing
+mitigation. AVX disabled as mitigation.
  Mitigation: Microcode  Processor is vulnerable and mitigation is in
 effect.
  Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1457,7 +1457,13 @@
 
This issue is mitigated by default in updated microcode.
The mitigation may have a performance impact but can be
-   disabled.
+   disabled. On systems without the microcode mitigation
+   disabling AVX serves as a 

bug#65168: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 5.15-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/speculation: Add force option to GDS mitigation

to the 5.15-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-speculation-add-force-option-to-gds-mitigation.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From cabb00095114a40cc96f3d7766ad1a542f7f8c53 Mon Sep 17 00:00:00 2001
From: Daniel Sneddon 
Date: Tue, 1 Aug 2023 18:58:31 +0200
Subject: x86/speculation: Add force option to GDS mitigation

From: Daniel Sneddon 

commit 553a5c03e90a6087e88f8ff878335ef0621536fb upstream

The Gather Data Sampling (GDS) vulnerability allows malicious software
to infer stale data previously stored in vector registers. This may
include sensitive data such as cryptographic keys. GDS is mitigated in
microcode, and systems with up-to-date microcode are protected by
default. However, any affected system that is running with older
microcode will still be vulnerable to GDS attacks.

Since the gather instructions used by the attacker are part of the
AVX2 and AVX512 extensions, disabling these extensions prevents gather
instructions from being executed, thereby mitigating the system from
GDS. Disabling AVX2 is sufficient, but we don't have the granularity
to do this. The XCR0[2] disables AVX, with no option to just disable
AVX2.

Add a kernel parameter gather_data_sampling=force that will enable the
microcode mitigation if available, otherwise it will disable AVX on
affected systems.

This option will be ignored if cmdline mitigations=off.

This is a *big* hammer.  It is known to break buggy userspace that
uses incomplete, buggy AVX enumeration.  Unfortunately, such userspace
does exist in the wild:

https://www.mail-archive.com/bug-coreutils@gnu.org/msg33046.html

[ dhansen: add some more ominous warnings about disabling AVX ]

Signed-off-by: Daniel Sneddon 
Signed-off-by: Dave Hansen 
Acked-by: Josh Poimboeuf 
Signed-off-by: Daniel Sneddon 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/admin-guide/hw-vuln/gather_data_sampling.rst |   18 +--
 Documentation/admin-guide/kernel-parameters.txt|8 -
 arch/x86/kernel/cpu/bugs.c |   20 -
 3 files changed, 40 insertions(+), 6 deletions(-)

--- a/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
+++ b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
@@ -60,14 +60,21 @@ bits:
     ===   
 
 GDS can also be mitigated on systems that don't have updated microcode by
-disabling AVX. This can be done by setting "clearcpuid=avx" on the kernel
-command-line.
+disabling AVX. This can be done by setting gather_data_sampling="force" or
+"clearcpuid=avx" on the kernel command-line.
+
+If used, these options will disable AVX use by turning on XSAVE YMM support.
+However, the processor will still enumerate AVX support.  Userspace that
+does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
+support will break.
 
 Mitigation control on the kernel command line
 -
 The mitigation can be disabled by setting "gather_data_sampling=off" or
-"mitigations=off" on the kernel command line. Not specifying either will
-default to the mitigation being enabled.
+"mitigations=off" on the kernel command line. Not specifying either will 
default
+to the mitigation being enabled. Specifying "gather_data_sampling=force" will
+use the microcode mitigation when available or disable AVX on affected systems
+where the microcode hasn't been updated to include the mitigation.
 
 GDS System Information
 
@@ -83,6 +90,9 @@ The possible values contained in this fi
  Vulnerable Processor vulnerable and mitigation disabled.
  Vulnerable: No microcode   Processor vulnerable and microcode is missing
 mitigation.
+ Mitigation: AVX disabled,
+ no microcode   Processor is vulnerable and microcode is 
missing
+mitigation. AVX disabled as mitigation.
  Mitigation: Microcode  Processor is vulnerable and mitigation is in
 effect.
  Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1511,7 +1511,13 @@
 
This issue is mitigated by default in updated microcode.
The mitigation may have a performance impact but can be
-   disabled.
+   disabled. On systems without the microcode mitigation
+   disabling AVX serves as a 

bug#65165: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 4.19-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/speculation: Add force option to GDS mitigation

to the 4.19-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-speculation-add-force-option-to-gds-mitigation.patch
and it can be found in the queue-4.19 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From ead252286b6800873dd961075a36939f15e9b163 Mon Sep 17 00:00:00 2001
From: Daniel Sneddon 
Date: Wed, 12 Jul 2023 19:43:12 -0700
Subject: x86/speculation: Add force option to GDS mitigation

From: Daniel Sneddon 

commit 553a5c03e90a6087e88f8ff878335ef0621536fb upstream

The Gather Data Sampling (GDS) vulnerability allows malicious software
to infer stale data previously stored in vector registers. This may
include sensitive data such as cryptographic keys. GDS is mitigated in
microcode, and systems with up-to-date microcode are protected by
default. However, any affected system that is running with older
microcode will still be vulnerable to GDS attacks.

Since the gather instructions used by the attacker are part of the
AVX2 and AVX512 extensions, disabling these extensions prevents gather
instructions from being executed, thereby mitigating the system from
GDS. Disabling AVX2 is sufficient, but we don't have the granularity
to do this. The XCR0[2] disables AVX, with no option to just disable
AVX2.

Add a kernel parameter gather_data_sampling=force that will enable the
microcode mitigation if available, otherwise it will disable AVX on
affected systems.

This option will be ignored if cmdline mitigations=off.

This is a *big* hammer.  It is known to break buggy userspace that
uses incomplete, buggy AVX enumeration.  Unfortunately, such userspace
does exist in the wild:

https://www.mail-archive.com/bug-coreutils@gnu.org/msg33046.html

[ dhansen: add some more ominous warnings about disabling AVX ]

Signed-off-by: Daniel Sneddon 
Signed-off-by: Dave Hansen 
Acked-by: Josh Poimboeuf 
Signed-off-by: Daniel Sneddon 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/admin-guide/hw-vuln/gather_data_sampling.rst |   18 +--
 Documentation/admin-guide/kernel-parameters.txt|8 -
 arch/x86/kernel/cpu/bugs.c |   20 -
 3 files changed, 40 insertions(+), 6 deletions(-)

--- a/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
+++ b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
@@ -60,14 +60,21 @@ bits:
     ===   
 
 GDS can also be mitigated on systems that don't have updated microcode by
-disabling AVX. This can be done by setting "clearcpuid=avx" on the kernel
-command-line.
+disabling AVX. This can be done by setting gather_data_sampling="force" or
+"clearcpuid=avx" on the kernel command-line.
+
+If used, these options will disable AVX use by turning on XSAVE YMM support.
+However, the processor will still enumerate AVX support.  Userspace that
+does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
+support will break.
 
 Mitigation control on the kernel command line
 -
 The mitigation can be disabled by setting "gather_data_sampling=off" or
-"mitigations=off" on the kernel command line. Not specifying either will
-default to the mitigation being enabled.
+"mitigations=off" on the kernel command line. Not specifying either will 
default
+to the mitigation being enabled. Specifying "gather_data_sampling=force" will
+use the microcode mitigation when available or disable AVX on affected systems
+where the microcode hasn't been updated to include the mitigation.
 
 GDS System Information
 
@@ -83,6 +90,9 @@ The possible values contained in this fi
  Vulnerable Processor vulnerable and mitigation disabled.
  Vulnerable: No microcode   Processor vulnerable and microcode is missing
 mitigation.
+ Mitigation: AVX disabled,
+ no microcode   Processor is vulnerable and microcode is 
missing
+mitigation. AVX disabled as mitigation.
  Mitigation: Microcode  Processor is vulnerable and mitigation is in
 effect.
  Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1300,7 +1300,13 @@
 
This issue is mitigated by default in updated microcode.
The mitigation may have a performance impact but can be
-   disabled.
+   disabled. On systems without the microcode mitigation
+   disabling AVX serves as a 

bug#65166: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 5.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/speculation: Add force option to GDS mitigation

to the 5.4-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-speculation-add-force-option-to-gds-mitigation.patch
and it can be found in the queue-5.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From ead252286b6800873dd961075a36939f15e9b163 Mon Sep 17 00:00:00 2001
From: Daniel Sneddon 
Date: Wed, 12 Jul 2023 19:43:12 -0700
Subject: x86/speculation: Add force option to GDS mitigation

From: Daniel Sneddon 

commit 553a5c03e90a6087e88f8ff878335ef0621536fb upstream

The Gather Data Sampling (GDS) vulnerability allows malicious software
to infer stale data previously stored in vector registers. This may
include sensitive data such as cryptographic keys. GDS is mitigated in
microcode, and systems with up-to-date microcode are protected by
default. However, any affected system that is running with older
microcode will still be vulnerable to GDS attacks.

Since the gather instructions used by the attacker are part of the
AVX2 and AVX512 extensions, disabling these extensions prevents gather
instructions from being executed, thereby mitigating the system from
GDS. Disabling AVX2 is sufficient, but we don't have the granularity
to do this. The XCR0[2] disables AVX, with no option to just disable
AVX2.

Add a kernel parameter gather_data_sampling=force that will enable the
microcode mitigation if available, otherwise it will disable AVX on
affected systems.

This option will be ignored if cmdline mitigations=off.

This is a *big* hammer.  It is known to break buggy userspace that
uses incomplete, buggy AVX enumeration.  Unfortunately, such userspace
does exist in the wild:

https://www.mail-archive.com/bug-coreutils@gnu.org/msg33046.html

[ dhansen: add some more ominous warnings about disabling AVX ]

Signed-off-by: Daniel Sneddon 
Signed-off-by: Dave Hansen 
Acked-by: Josh Poimboeuf 
Signed-off-by: Daniel Sneddon 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/admin-guide/hw-vuln/gather_data_sampling.rst |   18 +--
 Documentation/admin-guide/kernel-parameters.txt|8 -
 arch/x86/kernel/cpu/bugs.c |   20 -
 3 files changed, 40 insertions(+), 6 deletions(-)

--- a/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
+++ b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
@@ -60,14 +60,21 @@ bits:
     ===   
 
 GDS can also be mitigated on systems that don't have updated microcode by
-disabling AVX. This can be done by setting "clearcpuid=avx" on the kernel
-command-line.
+disabling AVX. This can be done by setting gather_data_sampling="force" or
+"clearcpuid=avx" on the kernel command-line.
+
+If used, these options will disable AVX use by turning on XSAVE YMM support.
+However, the processor will still enumerate AVX support.  Userspace that
+does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
+support will break.
 
 Mitigation control on the kernel command line
 -
 The mitigation can be disabled by setting "gather_data_sampling=off" or
-"mitigations=off" on the kernel command line. Not specifying either will
-default to the mitigation being enabled.
+"mitigations=off" on the kernel command line. Not specifying either will 
default
+to the mitigation being enabled. Specifying "gather_data_sampling=force" will
+use the microcode mitigation when available or disable AVX on affected systems
+where the microcode hasn't been updated to include the mitigation.
 
 GDS System Information
 
@@ -83,6 +90,9 @@ The possible values contained in this fi
  Vulnerable Processor vulnerable and mitigation disabled.
  Vulnerable: No microcode   Processor vulnerable and microcode is missing
 mitigation.
+ Mitigation: AVX disabled,
+ no microcode   Processor is vulnerable and microcode is 
missing
+mitigation. AVX disabled as mitigation.
  Mitigation: Microcode  Processor is vulnerable and mitigation is in
 effect.
  Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1346,7 +1346,13 @@
 
This issue is mitigated by default in updated microcode.
The mitigation may have a performance impact but can be
-   disabled.
+   disabled. On systems without the microcode mitigation
+   disabling AVX serves as a 

bug#65169: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 6.1-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/speculation: Add force option to GDS mitigation

to the 6.1-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-speculation-add-force-option-to-gds-mitigation.patch
and it can be found in the queue-6.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From a618486444bfe6f235f76ff547eec914f5dda9ce Mon Sep 17 00:00:00 2001
From: Daniel Sneddon 
Date: Tue, 1 Aug 2023 16:36:26 +0200
Subject: x86/speculation: Add force option to GDS mitigation

From: Daniel Sneddon 

commit 553a5c03e90a6087e88f8ff878335ef0621536fb upstream

The Gather Data Sampling (GDS) vulnerability allows malicious software
to infer stale data previously stored in vector registers. This may
include sensitive data such as cryptographic keys. GDS is mitigated in
microcode, and systems with up-to-date microcode are protected by
default. However, any affected system that is running with older
microcode will still be vulnerable to GDS attacks.

Since the gather instructions used by the attacker are part of the
AVX2 and AVX512 extensions, disabling these extensions prevents gather
instructions from being executed, thereby mitigating the system from
GDS. Disabling AVX2 is sufficient, but we don't have the granularity
to do this. The XCR0[2] disables AVX, with no option to just disable
AVX2.

Add a kernel parameter gather_data_sampling=force that will enable the
microcode mitigation if available, otherwise it will disable AVX on
affected systems.

This option will be ignored if cmdline mitigations=off.

This is a *big* hammer.  It is known to break buggy userspace that
uses incomplete, buggy AVX enumeration.  Unfortunately, such userspace
does exist in the wild:

https://www.mail-archive.com/bug-coreutils@gnu.org/msg33046.html

[ dhansen: add some more ominous warnings about disabling AVX ]

Signed-off-by: Daniel Sneddon 
Signed-off-by: Dave Hansen 
Acked-by: Josh Poimboeuf 
Signed-off-by: Daniel Sneddon 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/admin-guide/hw-vuln/gather_data_sampling.rst |   18 +--
 Documentation/admin-guide/kernel-parameters.txt|8 -
 arch/x86/kernel/cpu/bugs.c |   20 -
 3 files changed, 40 insertions(+), 6 deletions(-)

--- a/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
+++ b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
@@ -60,14 +60,21 @@ bits:
     ===   
 
 GDS can also be mitigated on systems that don't have updated microcode by
-disabling AVX. This can be done by setting "clearcpuid=avx" on the kernel
-command-line.
+disabling AVX. This can be done by setting gather_data_sampling="force" or
+"clearcpuid=avx" on the kernel command-line.
+
+If used, these options will disable AVX use by turning on XSAVE YMM support.
+However, the processor will still enumerate AVX support.  Userspace that
+does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
+support will break.
 
 Mitigation control on the kernel command line
 -
 The mitigation can be disabled by setting "gather_data_sampling=off" or
-"mitigations=off" on the kernel command line. Not specifying either will
-default to the mitigation being enabled.
+"mitigations=off" on the kernel command line. Not specifying either will 
default
+to the mitigation being enabled. Specifying "gather_data_sampling=force" will
+use the microcode mitigation when available or disable AVX on affected systems
+where the microcode hasn't been updated to include the mitigation.
 
 GDS System Information
 
@@ -83,6 +90,9 @@ The possible values contained in this fi
  Vulnerable Processor vulnerable and mitigation disabled.
  Vulnerable: No microcode   Processor vulnerable and microcode is missing
 mitigation.
+ Mitigation: AVX disabled,
+ no microcode   Processor is vulnerable and microcode is 
missing
+mitigation. AVX disabled as mitigation.
  Mitigation: Microcode  Processor is vulnerable and mitigation is in
 effect.
  Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1603,7 +1603,13 @@
 
This issue is mitigated by default in updated microcode.
The mitigation may have a performance impact but can be
-   disabled.
+   disabled. On systems without the microcode mitigation
+   disabling AVX serves as a 

bug#65170: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 6.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/speculation: Add force option to GDS mitigation

to the 6.4-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-speculation-add-force-option-to-gds-mitigation.patch
and it can be found in the queue-6.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From d9094016758575d1651bdde3ae3dd14aac20cfc5 Mon Sep 17 00:00:00 2001
From: Daniel Sneddon 
Date: Tue, 1 Aug 2023 16:07:11 +0200
Subject: x86/speculation: Add force option to GDS mitigation

From: Daniel Sneddon 

commit 553a5c03e90a6087e88f8ff878335ef0621536fb upstream

The Gather Data Sampling (GDS) vulnerability allows malicious software
to infer stale data previously stored in vector registers. This may
include sensitive data such as cryptographic keys. GDS is mitigated in
microcode, and systems with up-to-date microcode are protected by
default. However, any affected system that is running with older
microcode will still be vulnerable to GDS attacks.

Since the gather instructions used by the attacker are part of the
AVX2 and AVX512 extensions, disabling these extensions prevents gather
instructions from being executed, thereby mitigating the system from
GDS. Disabling AVX2 is sufficient, but we don't have the granularity
to do this. The XCR0[2] disables AVX, with no option to just disable
AVX2.

Add a kernel parameter gather_data_sampling=force that will enable the
microcode mitigation if available, otherwise it will disable AVX on
affected systems.

This option will be ignored if cmdline mitigations=off.

This is a *big* hammer.  It is known to break buggy userspace that
uses incomplete, buggy AVX enumeration.  Unfortunately, such userspace
does exist in the wild:

https://www.mail-archive.com/bug-coreutils@gnu.org/msg33046.html

[ dhansen: add some more ominous warnings about disabling AVX ]

Signed-off-by: Daniel Sneddon 
Signed-off-by: Dave Hansen 
Acked-by: Josh Poimboeuf 
Signed-off-by: Daniel Sneddon 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/admin-guide/hw-vuln/gather_data_sampling.rst |   18 +--
 Documentation/admin-guide/kernel-parameters.txt|8 -
 arch/x86/kernel/cpu/bugs.c |   20 -
 3 files changed, 40 insertions(+), 6 deletions(-)

--- a/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
+++ b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
@@ -60,14 +60,21 @@ bits:
     ===   
 
 GDS can also be mitigated on systems that don't have updated microcode by
-disabling AVX. This can be done by setting "clearcpuid=avx" on the kernel
-command-line.
+disabling AVX. This can be done by setting gather_data_sampling="force" or
+"clearcpuid=avx" on the kernel command-line.
+
+If used, these options will disable AVX use by turning on XSAVE YMM support.
+However, the processor will still enumerate AVX support.  Userspace that
+does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
+support will break.
 
 Mitigation control on the kernel command line
 -
 The mitigation can be disabled by setting "gather_data_sampling=off" or
-"mitigations=off" on the kernel command line. Not specifying either will
-default to the mitigation being enabled.
+"mitigations=off" on the kernel command line. Not specifying either will 
default
+to the mitigation being enabled. Specifying "gather_data_sampling=force" will
+use the microcode mitigation when available or disable AVX on affected systems
+where the microcode hasn't been updated to include the mitigation.
 
 GDS System Information
 
@@ -83,6 +90,9 @@ The possible values contained in this fi
  Vulnerable Processor vulnerable and mitigation disabled.
  Vulnerable: No microcode   Processor vulnerable and microcode is missing
 mitigation.
+ Mitigation: AVX disabled,
+ no microcode   Processor is vulnerable and microcode is 
missing
+mitigation. AVX disabled as mitigation.
  Mitigation: Microcode  Processor is vulnerable and mitigation is in
 effect.
  Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1637,7 +1637,13 @@
 
This issue is mitigated by default in updated microcode.
The mitigation may have a performance impact but can be
-   disabled.
+   disabled. On systems without the microcode mitigation
+   disabling AVX serves as a 

bug#65164: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 4.14-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/speculation: Add force option to GDS mitigation

to the 4.14-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-speculation-add-force-option-to-gds-mitigation.patch
and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From ead252286b6800873dd961075a36939f15e9b163 Mon Sep 17 00:00:00 2001
From: Daniel Sneddon 
Date: Wed, 12 Jul 2023 19:43:12 -0700
Subject: x86/speculation: Add force option to GDS mitigation

From: Daniel Sneddon 

commit 553a5c03e90a6087e88f8ff878335ef0621536fb upstream

The Gather Data Sampling (GDS) vulnerability allows malicious software
to infer stale data previously stored in vector registers. This may
include sensitive data such as cryptographic keys. GDS is mitigated in
microcode, and systems with up-to-date microcode are protected by
default. However, any affected system that is running with older
microcode will still be vulnerable to GDS attacks.

Since the gather instructions used by the attacker are part of the
AVX2 and AVX512 extensions, disabling these extensions prevents gather
instructions from being executed, thereby mitigating the system from
GDS. Disabling AVX2 is sufficient, but we don't have the granularity
to do this. The XCR0[2] disables AVX, with no option to just disable
AVX2.

Add a kernel parameter gather_data_sampling=force that will enable the
microcode mitigation if available, otherwise it will disable AVX on
affected systems.

This option will be ignored if cmdline mitigations=off.

This is a *big* hammer.  It is known to break buggy userspace that
uses incomplete, buggy AVX enumeration.  Unfortunately, such userspace
does exist in the wild:

https://www.mail-archive.com/bug-coreutils@gnu.org/msg33046.html

[ dhansen: add some more ominous warnings about disabling AVX ]

Signed-off-by: Daniel Sneddon 
Signed-off-by: Dave Hansen 
Acked-by: Josh Poimboeuf 
Signed-off-by: Daniel Sneddon 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/admin-guide/hw-vuln/gather_data_sampling.rst |   18 +--
 Documentation/admin-guide/kernel-parameters.txt|8 -
 arch/x86/kernel/cpu/bugs.c |   20 -
 3 files changed, 40 insertions(+), 6 deletions(-)

--- a/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
+++ b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
@@ -60,14 +60,21 @@ bits:
     ===   
 
 GDS can also be mitigated on systems that don't have updated microcode by
-disabling AVX. This can be done by setting "clearcpuid=avx" on the kernel
-command-line.
+disabling AVX. This can be done by setting gather_data_sampling="force" or
+"clearcpuid=avx" on the kernel command-line.
+
+If used, these options will disable AVX use by turning on XSAVE YMM support.
+However, the processor will still enumerate AVX support.  Userspace that
+does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
+support will break.
 
 Mitigation control on the kernel command line
 -
 The mitigation can be disabled by setting "gather_data_sampling=off" or
-"mitigations=off" on the kernel command line. Not specifying either will
-default to the mitigation being enabled.
+"mitigations=off" on the kernel command line. Not specifying either will 
default
+to the mitigation being enabled. Specifying "gather_data_sampling=force" will
+use the microcode mitigation when available or disable AVX on affected systems
+where the microcode hasn't been updated to include the mitigation.
 
 GDS System Information
 
@@ -83,6 +90,9 @@ The possible values contained in this fi
  Vulnerable Processor vulnerable and mitigation disabled.
  Vulnerable: No microcode   Processor vulnerable and microcode is missing
 mitigation.
+ Mitigation: AVX disabled,
+ no microcode   Processor is vulnerable and microcode is 
missing
+mitigation. AVX disabled as mitigation.
  Mitigation: Microcode  Processor is vulnerable and mitigation is in
 effect.
  Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1242,7 +1242,13 @@
 
This issue is mitigated by default in updated microcode.
The mitigation may have a performance impact but can be
-   disabled.
+   disabled. On systems without the microcode mitigation
+   disabling AVX serves as a 

bug#64937: "who" reports funny dates

[Paul Eggert]

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.

bug#64937: boot time on Linux

[Bruno Haible]

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  DevicePIDnation Exit  B U  
Host
--- -- --- -- --   - -  

2023-08-02 16:56:15 bruno  seat0 15110 0 X  
:0
2023-08-08 15:47:48 reboot ~00 0   X


Similarly,

$ TZ=UTC ./who -a /var/run/utmp
   system boot  2023-08-08 15:47
bruno? seat02023-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/12023-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  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

bug#64937: "who" reports funny dates

[Bruno Haible]

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  

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

bug#64937: "who" reports funny dates

[Bruno Haible]

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 1 µsec. Thanks for the
suggestion.


2023-08-08  Bruno Haible  

readutmp: Get the boot time with higher precision.
Suggested by Thorsten Kukuk  in

.
* 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, ) >= 0)
+{
+  struct timespec result;
+  /* equivalent to:
+  if (clock_gettime (CLOCK_REALTIME, ) >= 0)
+  */
+  if (timespec_get (, TIME_UTC) >= 0)
+{
+  if (result.tv_nsec < up.tv_nsec)
+{
+  result.tv_nsec += 10;
+  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)

bug#64937: "who" reports funny dates

[Thorsten Kukuk via GNU coreutils Bug Reports]

On Tue, Aug 08, Robert Pluim wrote:

> > On Tue, 8 Aug 2023 14:29:27 +, Thorsten Kukuk  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)

bug#64937: "who" reports funny dates

[Bruno Haible]

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  

readutmp: Return entries with unbounded strings on all platforms.
Suggested  by Paul Eggert in
.
* 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.

From 622d2c0763777eb909a4fda5048238f524cc36f9 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Tue, 8 Aug 2023 17:36:10 +0200
Subject: [PATCH] readutmp: Return entries with unbounded strings on all
 platforms.

Suggested  by Paul Eggert in
.

* 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

bug#64937: "who" reports funny dates

[Robert Pluim]

> On Tue, 08 Aug 2023 18:11:20 +0200, Bruno Haible  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
-- 

bug#64937: "who" reports funny dates

[Bruno Haible]

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

bug#64937: "who" reports funny dates

[Bruno Haible]

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 
>  # 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  

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

bug#64937: "who" reports funny dates

[Bruno Haible]

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  

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
 

bug#64937: "who" reports funny dates

[Robert Pluim]

> On Tue, 8 Aug 2023 14:29:27 +, Thorsten Kukuk  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
-- 

bug#64937: "who" reports funny dates

[Thorsten Kukuk via GNU coreutils Bug Reports]

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)

bug#64937: "who" reports funny dates

[Bruno Haible]

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

bug#64937: "who" reports funny dates

[Thorsten Kukuk via GNU coreutils Bug Reports]

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)

bug#64937: "who" reports funny dates

[Paul Eggert]

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 .




   * 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 -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.

bug#64937: "who" reports funny dates

[Bruno Haible]

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/btmpowner

Ubuntu 23.04   rw-rw-r-- rw-rw-r--  rw-rwroot:utmp
Debian 12  rw-rw-r-- rw-rw-r--  rw-rwroot:utmp
Fedora Rawhide rw-rw-r-- rw-rw-r--  rw-rwroot:utmp
  context  initrc_var_run_t  wtmp_t faillog_t
openSUSE 15.5  rw-rw-r-- rw-rw-r--  rw-rwroot:utmp
Slackware 14   rw-rw-r-- rw-rw-r--  rw---root:utmp, 
btmp only root:root
Alpine 3.18rw-rw-r-- rw-rw-r--  rw-rwroot:utmp
Debian Hurdrw-rw-r-- rw-rw-r--  rw-rwroot: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:notty2023-08-07 13:06  2564 id=
$ sudo lastb
brunossh:notty127.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

bug#64937: "who" reports funny dates

[Paul Eggert]

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.

bug#64937: "who" reports funny dates

[Paul Eggert]

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  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.

bug#64937: "who" reports funny dates

[Thorsten Kukuk via GNU coreutils Bug Reports]

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  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)

bug#64937: "who" reports funny dates

[Thorsten Kukuk via GNU coreutils Bug Reports]

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)

bug#64937: "who" reports funny dates

[Paul Eggert]

On 2023-08-06 13:00, Paul Eggert wrote:


How does "last" emulate /var/log/wtmp using systemd?


Oh, I see from  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.

bug#64937: "who" reports funny dates

[Paul Eggert]

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/

bug#64937: "who" reports funny dates

[Paul Eggert]

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.From dcf286c586069684fe4d5bb2bd770394cd7cdad6 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 6 Aug 2023 12:43:05 -0700
Subject: [PATCH] readutmp: fix comment bug ID

* lib/readutmp.c: Fix comment (thanks to Bruno Haible).
---
 lib/readutmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/readutmp.c b/lib/readutmp.c
index b8eba076fa..4e1d7ec26b 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -47,7 +47,7 @@
 # pragma GCC diagnostic ignored "-Wsizeof-pointer-memaccess"
 #endif
 
-/* Work around .  */
+/* Work around .  */
 #if 11 <= __GNUC__
 # pragma GCC diagnostic ignored "-Wstringop-overread"
 #endif
-- 
2.39.2

bug#64937: "who" reports funny dates

[Bruno Haible]

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

bug#64937: "who" reports funny dates

[Bruno Haible]

Paul Eggert wrote:
> 0001-maint-Update-after-gnulib-module-readutmp-changed.patch

> +/* Work around ,
> +   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

bug#64937: "who" reports funny dates

[Thorsten Kukuk via GNU coreutils Bug Reports]

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)

bug#64937: "who" reports funny dates

[Paul Eggert]

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.From 39a4cb0afdf4f2a1e6c2f3176b84e5b4cfe8996d Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 3 Aug 2023 15:31:48 -0700
Subject: [PATCH 1/9] readutmp: simplify extract_trimmed_name via ximemdup0

* lib/readutmp.c (extract_trimmed_name): Simplify.
* modules/readutmp (Depends-on):
Add strnlen, which was a missing dependency.

* lib/readutmp.c: Include xmemdup0.
(extract_trimmed_name): Simplify.
* modules/readutmp (Depends-on): Add xmemdup0.
Add strnlen, which was a missing dependency already.
---
 ChangeLog|  7 +++
 lib/readutmp.c   | 28 +++-
 modules/readutmp |  1 +
 3 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b84cece6ff..7fa4e7b64a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2023-08-03  Paul Eggert  
+
+	readutmp: simplify extract_trimmed_name via ximemdup0
+	* lib/readutmp.c (extract_trimmed_name): Simplify.
+	* modules/readutmp (Depends-on):
+	Add strnlen, which was a missing dependency.
+
 2023-08-03  Bruno Haible  
 
 	alignasof, stdalign: Avoid some -Wundef warnings from config.h.
diff --git a/lib/readutmp.c b/lib/readutmp.c
index 11dd1655c5..9057a36494 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -47,29 +47,23 @@
 # pragma GCC diagnostic ignored "-Wsizeof-pointer-memaccess"
 #endif
 
+/* Work around .  */
+#if 11 <= __GNUC__
+# pragma GCC diagnostic ignored "-Wstringop-overread"
+#endif
+
 /* Copy UT_USER (UT) into storage obtained from malloc.  Then remove any
trailing spaces from the copy, NUL terminate it, and return the copy.  */
 
 char *
 extract_trimmed_name (const STRUCT_UTMP *ut)
 {
-  char *p, *trimmed_name;
-
-#if READUTMP_USE_SYSTEMD
-  trimmed_name = xstrdup (UT_USER (ut));
-#else
-  trimmed_name = xmalloc (UT_USER_SIZE + 1);
-  strncpy (trimmed_name, UT_USER (ut), UT_USER_SIZE);
-  /* Append a trailing NUL.  Some systems pad names shorter than the
- maximum with spaces, others pad with NULs.  */
-  trimmed_name[UT_USER_SIZE] = '\0';
-#endif
-  /* Remove any trailing spaces.  */
-  for (p = trimmed_name + strlen (trimmed_name);
-   trimmed_name < p && p[-1] == ' ';
-   *--p = '\0')
-;
-  return trimmed_name;
+  char const *name = UT_USER (ut);
+  idx_t len = strnlen (name, UT_USER_SIZE);
+  char const *p;
+  for (p = name + len; name < p && p[-1] == ' '; p--)
+continue;
+  return ximemdup0 (name, p - name);
 }
 
 #if READ_UTMP_SUPPORTED
diff --git a/modules/readutmp b/modules/readutmp
index 04893a4487..484edd1842 100644
--- a/modules/readutmp
+++ b/modules/readutmp
@@ -12,6 +12,7 @@ extensions
 xalloc
 stdbool
 stdint
+strnlen
 sys_time
 fopen-gnu
 unlocked-io-internal
-- 
2.39.2

From 1ccde926759e8638d4b86de3dabbd948ad921edc Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 3 Aug 2023 15:53:27 -0700
Subject: [PATCH 2/9] =?UTF-8?q?readutmp:=20go=20back=20to=20simple=20?=
 =?UTF-8?q?=E2=80=98free=E2=80=99?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Omit the new free_utmp function.  Instead, allocate storage
in one block, so that using code can still just call ‘free’.
* lib/readutmp.c (struct utmp_alloc) [READUTMP_USE_SYSTEMD]: New type.
(add_utmp) [READUTMP_USE_SYSTEMD]: New function.
(read_utmp) [READUTMP_USE_SYSTEMD]: Use it.
Also, use malloc a bit less heavily.
(free_utmp): Remove.
* tests/test-readutmp.c (main): Call free, not free_utmp.
---
 ChangeLog |  10 ++
 NEWS  |   4 +-
 lib/readutmp.c| 285 +++---
 lib/readutmp.h|   4 -
 tests/test-readutmp.c |   4 +-
 5 files changed, 167 insertions(+), 140 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 7fa4e7b64a..56b27d129f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,15 @@
 2023-08-03  Paul Eggert  
 
+	readutmp: go back to simple ‘free’
+	Omit the new free_utmp 

bug#64937: ssh sessions in systemd

[Thorsten Kukuk via GNU coreutils Bug Reports]

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)

bug#64937: session leaders pids

[Bruno Haible]

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 
(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
Description: application/compressed-tar

bug#64937: ssh sessions in systemd

[Bruno Haible]

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

bug#64937: ssh sessions in systemd

[Bruno Haible]

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

bug#65003: pinky's "Idle" column lost the unit

[Paul Eggert]

Thanks for reporting that; I installed the attached.From 93e30466ff6eec8a2cd66374e199017763821478 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Wed, 2 Aug 2023 06:47:13 -0700
Subject: [PATCH] pinky: fix "d" typo

Problem reported by Bruno Haible (bug#65003).
* src/pinky.c (idle_string): Fix recently-introduced typo:
missing "d" for "days".
---
 src/pinky.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/pinky.c b/src/pinky.c
index 381e753b6..b6d411c85 100644
--- a/src/pinky.c
+++ b/src/pinky.c
@@ -147,7 +147,7 @@ static char const *
 idle_string (time_t when)
 {
   static time_t now = 0;
-  static char buf[INT_STRLEN_BOUND (intmax_t) + 2];
+  static char buf[INT_STRLEN_BOUND (intmax_t) + sizeof "d"];
   time_t seconds_idle;
 
   if (now == 0)
@@ -165,7 +165,7 @@ idle_string (time_t when)
   else
 {
   intmax_t days = seconds_idle / (24 * 60 * 60);
-  sprintf (buf, "%"PRIdMAX, days);
+  sprintf (buf, "%"PRIdMAX"d", days);
 }
   return buf;
 }
-- 
2.39.2

bug#64937: "who" reports funny dates

[Bruno Haible]

I wrote:
> The proposed patch is attached.

Oops, I missed a sizeof of the ut_id field. A corrected patch is attached.

>From 97be578b107e7b87e32e0c3c2d49dc550489415b Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Wed, 2 Aug 2023 01:32:55 +0200
Subject: [PATCH] maint: Update after gnulib module 'readutmp' changed

For year-2038 safety on Linux/{x86,arm}, use systemd APIs.

* configure.ac: Don't test whether 'struct utmp' and 'struct utmpx' have
the ut_host field; this is now done in gnulib's readutmp module.
* src/system.h (STREQ_LEN): Allow passing a third argument with value
-1.
* src/pinky.c: Test HAVE_STRUCT_XTMP_UT_HOST instead of HAVE_UT_HOST.
(print_entry): Support the situation where ut_line is a 'char *' rather
than a 'char[]' of fixed size. Likewise for ut_user and ut_host.
* src/who.c: Test HAVE_STRUCT_XTMP_UT_HOST instead of HAVE_UT_HOST.
(print_user): Support the situation where ut_line is a 'char *' rather
than a 'char[]' of fixed size. Likewise for ut_user and ut_host.
(print_deadprocs, print_login, print_initspawn, scan_entries): Likewise.
(make_id_equals_comment): Likewise for ut_id.
(who): Free resources before returning.
* src/users.c (users): Free resources before returning.
* src/local.mk: Link the programs 'pinky', 'uptime', 'users', 'who' with
$(READUTMP_LIB).
---
 configure.ac | 30 --
 src/local.mk |  6 ++
 src/pinky.c  | 41 ++--
 src/system.h |  6 +-
 src/users.c  |  1 +
 src/who.c| 59 
 6 files changed, 83 insertions(+), 60 deletions(-)

diff --git a/configure.ac b/configure.ac
index 33441a82f..afc1098f7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -406,36 +406,6 @@ AC_DEFUN([coreutils_DUMMY_1],
 ])
 coreutils_DUMMY_1
 
-AC_MSG_CHECKING([ut_host in struct utmp])
-AC_CACHE_VAL([su_cv_func_ut_host_in_utmp],
-[AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include 
-   #include 
-   struct utmp ut;
-   int s = sizeof ut.ut_host;]])],
-  [su_cv_func_ut_host_in_utmp=yes],
-  [su_cv_func_ut_host_in_utmp=no])])
-AC_MSG_RESULT([$su_cv_func_ut_host_in_utmp])
-if test $su_cv_func_ut_host_in_utmp = yes; then
-  have_ut_host=1
-  AC_DEFINE([HAVE_UT_HOST], [1], [FIXME])
-fi
-
-if test -z "$have_ut_host"; then
-  AC_MSG_CHECKING([ut_host in struct utmpx])
-  AC_CACHE_VAL([su_cv_func_ut_host_in_utmpx],
-  [AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include 
- #include 
- struct utmpx ut;
- int s = sizeof ut.ut_host;]])],
-[su_cv_func_ut_host_in_utmpx=yes],
-[su_cv_func_ut_host_in_utmpx=no])])
-  AC_MSG_RESULT([$su_cv_func_ut_host_in_utmpx])
-  if test $su_cv_func_ut_host_in_utmpx = yes; then
-AC_DEFINE([HAVE_UTMPX_H], [1], [FIXME])
-AC_DEFINE([HAVE_UT_HOST], [1], [FIXME])
-  fi
-fi
-
 GNULIB_BOOT_TIME([gl_ADD_PROG([optional_bin_progs], [uptime])])
 
 AC_SYS_POSIX_TERMIOS()
diff --git a/src/local.mk b/src/local.mk
index cb9b39274..4d7df2789 100644
--- a/src/local.mk
+++ b/src/local.mk
@@ -317,6 +317,12 @@ src_who_LDADD += $(GETADDRINFO_LIB)
 src_hostname_LDADD += $(GETHOSTNAME_LIB)
 src_uname_LDADD += $(GETHOSTNAME_LIB)
 
+# for read_utmp
+src_pinky_LDADD += $(READUTMP_LIB)
+src_uptime_LDADD += $(READUTMP_LIB)
+src_users_LDADD += $(READUTMP_LIB)
+src_who_LDADD += $(READUTMP_LIB)
+
 # for strsignal
 src_kill_LDADD += $(LIBTHREAD)
 
diff --git a/src/pinky.c b/src/pinky.c
index 381e753b6..47abd7758 100644
--- a/src/pinky.c
+++ b/src/pinky.c
@@ -62,7 +62,7 @@ static bool include_home_and_shell = true;
 static bool do_short_format = true;
 
 /* if true, display the ut_host field. */
-#ifdef HAVE_UT_HOST
+#if HAVE_STRUCT_XTMP_UT_HOST
 static bool include_where = true;
 #endif
 
@@ -206,7 +206,8 @@ print_entry (const STRUCT_UTMP *utmp_ent)
 #define DEV_DIR_WITH_TRAILING_SLASH "/dev/"
 #define DEV_DIR_LEN (sizeof (DEV_DIR_WITH_TRAILING_SLASH) - 1)
 
-  char line[sizeof (utmp_ent->ut_line) + DEV_DIR_LEN + 1];
+#ifdef UT_LINE_SIZE
+  char line[DEV_DIR_LEN + UT_LINE_SIZE + 1];
   char *p = line;
 
   /* Copy ut_line into LINE, prepending '/dev/' if ut_line is not
@@ -214,7 +215,18 @@ print_entry (const STRUCT_UTMP *utmp_ent)
  absolute file name in ut_line.  */
   if ( ! IS_ABSOLUTE_FILE_NAME (utmp_ent->ut_line))
 p = stpcpy (p, DEV_DIR_WITH_TRAILING_SLASH);
-  stzncpy (p, utmp_ent->ut_line, sizeof (utmp_ent->ut_line));
+  stzncpy (p, utmp_ent->ut_line, UT_LINE_SIZE);
+#else
+  /* If ut_line contains a space, the device name starts after the space,
+ else at the beginning.  */
+  char *line = xmalloc (DEV_DIR_LEN + strlen (utmp_ent->ut_line) + 1);
+  char *space = strchr (utmp_ent->ut_line, ' ');
+  char *device = (space != NULL ? space + 1 : utmp_ent->ut_line);
+  if ( ! IS_ABSOLUTE_FILE_NAME (device))
+stpcpy (stpcpy (line, DEV_DIR_WITH_TRAILING_SLASH), device);
+  

bug#64937: "who" reports funny dates

[Thorsten Kukuk via GNU coreutils Bug Reports]

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)

bug#65003: pinky's "Idle" column lost the unit

[P]

I think this may be fixed with
https://github.com/coreutils/coreutils/commit/e886b300
Not at a computer to check

bug#65003: pinky's "Idle" column lost the unit

[Bruno Haible]

Hi Paul,

Two days ago, 'pinky's output looked like this:

Login TTY  Idle   When
bruno?seat0?  2023-07-30 11:25
bruno tty2 2d 2023-07-30 11:25
...

Today, it looks like this:

Login TTY  Idle   When
bruno?seat0?  2023-07-30 11:25
bruno tty2 2  2023-07-30 11:25
...

In the Idle column, the "d" (which stands for days) is gone.

This is a regression. Looks like it was caused by commit
0b2796750ff68eb58616655236d7003f6d30223a , today.

Bruno

bug#64937: "who" reports funny dates

[Bruno Haible]

> 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:

brunoseat02023-07-30 11:25   ?  1663 (login screen)
brunotty2 2023-07-30 11:25  old 1663 (tty2)
brunopts/32023-08-01 01:36 22:33   30619 (:0)
otherpts/42023-08-01 17:19 06:50   40513 (::1)

With systemd:

othersshd pts/4   2023-08-01 17:19 06:50   40513 (::1)
brunoseat02023-07-30 11:25   ?  1593
brunotty2 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:

LoginName TTY  Idle   When Where
brunoBruno Haible?seat0?  2023-07-30 11:25 login screen
brunoBruno Haible tty2 2d 2023-07-30 11:25 tty2
brunoBruno Haible pts/322:39  2023-08-01 01:36 :0

With systemd:

LoginName TTY  Idle   When Where
brunoBruno Haible?seat0?  2023-07-30 11:25
brunoBruno 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.

>From d80eea8fb087e9504a6dad27e1a880227f67915a Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Wed, 2 Aug 2023 01:32:55 +0200
Subject: [PATCH] maint: Update after gnulib module 'readutmp' changed

For year-2038 safety on Linux/{x86,arm}, use systemd APIs.

* configure.ac: Don't test whether 'struct utmp' and 'struct utmpx' have
the ut_host field; this is now done in gnulib's readutmp module.
* src/system.h (STREQ_LEN): Allow passing a third argument with value
-1.
* src/pinky.c: Test HAVE_STRUCT_XTMP_UT_HOST instead of HAVE_UT_HOST.
(print_entry): Support the situation where ut_line is a 'char *' rather
than a 'char[]' of fixed size. Likewise for ut_user and ut_host.
* src/who.c: Test HAVE_STRUCT_XTMP_UT_HOST instead of HAVE_UT_HOST.
(print_user): Support the situation where ut_line is a 'char *' rather
than a 'char[]' of fixed size. Likewise for ut_user and ut_host.
(print_deadprocs, print_login, print_initspawn, scan_entries): Likewise.
(who): Free resources before returning.
* src/users.c (users): Free resources before returning.
* src/local.mk: Link the programs 'pinky', 'uptime', 'users', 'who' with
$(READUTMP_LIB).
---
 configure.ac | 30 --
 src/local.mk |  6 ++
 src/pinky.c  | 41 ++---
 src/system.h |  6 +-
 src/users.c  |  1 +
 src/who.c| 44 ++--
 6 files changed, 72 insertions(+), 56 deletions(-)

diff --git a/configure.ac b/configure.ac
index 33441a82f..afc1098f7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -406,36 +406,6 @@ AC_DEFUN([coreutils_DUMMY_1],
 ])
 coreutils_DUMMY_1
 
-AC_MSG_CHECKING([ut_host in struct utmp])
-AC_CACHE_VAL([su_cv_func_ut_host_in_utmp],
-[AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include 
-   #include 
-   struct utmp ut;
-   int s = sizeof ut.ut_host;]])],
-  [su_cv_func_ut_host_in_utmp=yes],
-  [su_cv_func_ut_host_in_utmp=no])])
-AC_MSG_RESULT([$su_cv_func_ut_host_in_utmp])
-if test $su_cv_func_ut_host_in_utmp = yes; then
-  have_ut_host=1
-  AC_DEFINE([HAVE_UT_HOST], [1], [FIXME])
-fi
-
-if test -z "$have_ut_host"; then
-  AC_MSG_CHECKING([ut_host in struct utmpx])
-  AC_CACHE_VAL([su_cv_func_ut_host_in_utmpx],
-  [AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include 
- #include 
- struct utmpx ut;
- int s = sizeof ut.ut_host;]])],
-[su_cv_func_ut_host_in_utmpx=yes],
-[su_cv_func_ut_host_in_utmpx=no])])
-  AC_MSG_RESULT([$su_cv_func_ut_host_in_utmpx])
-  if test $su_cv_func_ut_host_in_utmpx = yes; then
-AC_DEFINE([HAVE_UTMPX_H], [1], 

bug#64937: "who" reports funny dates

[Bruno Haible]

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
. 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  

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  

readutmp: For year-2038 safety on Linux/{x86,arm}, use systemd APIs.
Suggested by Thorsten Kukuk  in
 and
.
* 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  and
.
(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  DevicePIDnation Exit  B U
--- -- --- -- --   - -
2023-07-30 09:25:15 reboot ~00 0   X  
2023-07-30 09:25:31 runlevel   ~   530 0  
2023-07-30 09:25:48 bruno  seat0 16630 0 X
2023-07-30 09:25:48 bruno  tty2  16630 0 X
2023-07-30 09:31:17pts/1 32100 0  
2023-07-31 23:36:52 bruno  pts/3306190 0 X
2023-08-01 15:19:26 other  pts/4405130 0 X
2023-08-01 19:02:20pts/5433760 1  
 ==

with libsystemd it is:

 

bug#64954: GNU 'uptime' on OpenBSD always prints "0 users"

[Paul Eggert]

Thanks, I propagated that into Coreutils and installed the simplified 
patch I mentioned yesterday. Closing the coreutils bug report.

bug#64954: GNU 'uptime' on OpenBSD always prints "0 users"

[Bruno Haible]

I wrote in :
>   - Gnulib modules should better provide .h files that can be #included
> on any platform. Thus, it's Gnulib's task to provide a readutmp.h
> and a read_utmp() function that can also be used on native Windows.

Done as follows:


2023-07-31  Bruno Haible  

readutmp: Make the header file and function usable on all platforms.
* lib/readutmp.h (struct gl_utmp, UTMP_STRUCT_NAME, UT_TIME_MEMBER,
UT_EXIT_E_TERMINATION, UT_EXIT_E_EXIT, UT_USER): Provide fallback
definitions.
(READ_UTMP_SUPPORTED): New macro.
* lib/readutmp.c (read_utmp) [!READ_UTMP_SUPPORTED]: Provide a dummy
definition.
* modules/readutmp (Depends-on): Add sys_time.
(configure.ac): Remove conditional.
(Makefile.am): Compile readutmp.c on all platforms.
(Include): Include readutmp.h on all platforms.
* tests/test-readutmp.c: Include readutmp.h on all platforms.
(main): Invoke read_utmp on all platforms.

diff --git a/lib/readutmp.c b/lib/readutmp.c
index acffe1000e..af43d1ad6b 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -61,6 +61,8 @@ extract_trimmed_name (const STRUCT_UTMP *ut)
   return trimmed_name;
 }
 
+#if READ_UTMP_SUPPORTED
+
 /* Is the utmp entry U desired by the user who asked for OPTIONS?  */
 
 static bool
@@ -77,12 +79,12 @@ desirable_utmp_entry (STRUCT_UTMP const *u, int options)
   return true;
 }
 
-#ifdef UTMP_NAME_FUNCTION
+# if defined UTMP_NAME_FUNCTION
 
 static void
 copy_utmp_entry (STRUCT_UTMP *dst, STRUCT_UTMP *src)
 {
-#if __GLIBC__ && _TIME_BITS == 64
+#  if __GLIBC__ && _TIME_BITS == 64
   /* Convert from external form in SRC to internal form in DST.
  It is OK to convert now, rather than earlier, before
  desirable_utmp_entry was invoked, because desirable_utmp_entry
@@ -119,9 +121,9 @@ copy_utmp_entry (STRUCT_UTMP *dst, STRUCT_UTMP *src)
   dst->ut_tv.tv_sec = s->ut_tv.tv_sec;
   dst->ut_tv.tv_usec = s->ut_tv.tv_usec;
   memcpy (>ut_addr_v6, s->ut_addr_v6, sizeof dst->ut_addr_v6);
-#else
+#  else
   *dst = *src;
-#endif
+#  endif
 }
 
 int
@@ -158,7 +160,7 @@ read_utmp (char const *file, size_t *n_entries, STRUCT_UTMP 
**utmp_buf,
   return 0;
 }
 
-#else
+# else
 
 int
 read_utmp (char const *file, size_t *n_entries, STRUCT_UTMP **utmp_buf,
@@ -198,4 +200,16 @@ read_utmp (char const *file, size_t *n_entries, 
STRUCT_UTMP **utmp_buf,
   return 0;
 }
 
+# endif
+
+#else /* dummy fallback */
+
+int
+read_utmp (char const *file, size_t *n_entries, STRUCT_UTMP **utmp_buf,
+   int options)
+{
+  errno = ENOSYS;
+  return -1;
+}
+
 #endif
diff --git a/lib/readutmp.h b/lib/readutmp.h
index 7d2a628135..d710699525 100644
--- a/lib/readutmp.h
+++ b/lib/readutmp.h
@@ -38,6 +38,7 @@
 # endif
 
 # if HAVE_UTMPX_H
+
 #  if HAVE_UTMP_H
 /* HPUX 10.20 needs utmp.h, for the definition of e.g., UTMP_FILE.  */
 #   include 
@@ -114,6 +115,24 @@
 #   endif
 #  endif
 
+# else
+
+/* Provide a dummy fallback.  */
+
+/* Get 'struct timeval'.  */
+#  include 
+
+struct gl_utmp
+{
+  char ut_user[1];
+  char ut_line[1];
+  struct timeval ut_tv;
+};
+#  define UTMP_STRUCT_NAME gl_utmp
+#  define UT_TIME_MEMBER(UT_PTR) ((UT_PTR)->ut_tv.tv_sec)
+#  define UT_EXIT_E_TERMINATION(U) 0
+#  define UT_EXIT_E_EXIT(U) 0
+
 # endif
 
 /* Accessor macro for the member named ut_user or ut_name.  */
@@ -137,6 +156,10 @@
 #   define UT_USER(Utmp) ((Utmp)->ut_name)
 #  endif
 
+# else /* dummy fallback */
+
+#  define UT_USER(Utmp) ((Utmp)->ut_user)
+
 # endif
 
 # define HAVE_STRUCT_XTMP_UT_EXIT \
@@ -151,10 +174,14 @@
 (HAVE_STRUCT_UTMP_UT_PID \
  || HAVE_STRUCT_UTMPX_UT_PID)
 
+/* Type of entry returned by read_utmp().  */
 typedef struct UTMP_STRUCT_NAME STRUCT_UTMP;
 
+/* Size of the UT_USER (ut) member.  */
 enum { UT_USER_SIZE = sizeof UT_USER ((STRUCT_UTMP *) 0) };
 
+/* Definition of UTMP_FILE and WTMP_FILE.  */
+
 # if !defined UTMP_FILE && defined _PATH_UTMP
 #  define UTMP_FILE _PATH_UTMP
 # endif
@@ -181,12 +208,15 @@ enum { UT_USER_SIZE = sizeof UT_USER ((STRUCT_UTMP *) 0) 
};
 #  define WTMP_FILE "/etc/wtmp"
 # endif
 
+/* Accessor macro for the member named ut_pid.  */
 # if HAVE_STRUCT_XTMP_UT_PID
 #  define UT_PID(U) ((U)->ut_pid)
 # else
 #  define UT_PID(U) 0
 # endif
 
+/* Accessor macros for the member named ut_type.  */
+
 # if HAVE_STRUCT_UTMP_UT_TYPE || HAVE_STRUCT_UTMPX_UT_TYPE
 #  define UT_TYPE_EQ(U, V) ((U)->ut_type == (V))
 #  define UT_TYPE_NOT_DEFINED 0
@@ -207,11 +237,17 @@ enum { UT_USER_SIZE = sizeof UT_USER ((STRUCT_UTMP *) 0) 
};
 #  define UT_TYPE_USER_PROCESS(U) 0
 # endif
 
+/* Determines whether an entry *U corresponds to a user process.  */
 # define IS_USER_PROCESS(U) \
(UT_USER (U)[0]  \
 && (UT_TYPE_USER_PROCESS (U)\
 || (UT_TYPE_NOT_DEFINED && UT_TIME_MEMBER (U) != 0)))
 

bug#64937: "who" reports funny dates

[Thorsten Kukuk via GNU coreutils Bug Reports]

Hi,

On Sun, Jul 30, Paul Eggert wrote:

> Thorsten's draft coreutils patches 
>  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  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)

bug#64954: GNU 'uptime' on OpenBSD always prints "0 users"

[Bruno Haible]

Paul Eggert wrote:
> > I'm fine with the change, but we'll also need to adjust
> > the sc_prohibit_always_true_header_tests syntax check in gnulib
> 
> I looked into that but it's such a hassle that I came up with the 
> attached simpler patch to Coreutils. How about installing it instead?

Yes, that's better than what I proposed, on two accounts:
  - Gnulib modules should better provide .h files that can be #included
on any platform. Thus, it's Gnulib's task to provide a readutmp.h
and a read_utmp() function that can also be used on native Windows.
  - It gets rid of the horrible hack to pass the values of two uninitialized
variables down to a function.

Pádraig Brady wrote:
> gnulib docs
> state the following platforms have neither getutent or getutxent,
> and so might have issues with this?

OpenBSD 6.7, Minix 3.1.8, mingw, MSVC 14

On these platforms the #include "readutmp.h" would already provoke a
mass of syntax errors.

Btw, we don't test on Minix any longer (since Minix is dead),
and OpenBSD 6.x is end-of-life already [1].

Bruno

https://en.wikipedia.org/wiki/OpenBSD#Releases

bug#64954: GNU 'uptime' on OpenBSD always prints "0 users"

[Pádraig Brady]

On 30/07/2023 20:43, Paul Eggert wrote:

On 2023-07-30 11:41, Pádraig Brady wrote:

I'm fine with the change, but we'll also need to adjust
the sc_prohibit_always_true_header_tests syntax check in gnulib


I looked into that but it's such a hassle that I came up with the
attached simpler patch to Coreutils. How about installing it instead? No
Gnulib change should be needed.


Maybe, though I notice that gnulib docs
state the following platforms have neither getutent or getutxent,
and so might have issues with this?

OpenBSD 6.7, Minix 3.1.8, mingw, MSVC 14

bug#64937: "who" reports funny dates

[Paul Eggert]

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.