Recent update appears to have broken last and lastb

[neildarlow]

Hi,

I've been using archlinuxARM on v7h hardware for several years now with nothing more major that not having the latest kernel version available.

After the latest update I've noticed that the [b]last[/b] and [b]lastb[/b] commands appear to be broken. I SSH into this system and I recall there was a vulnerability recently relating to SSH and wtmp but it's my understanding that archlinux, in general, wasn't susceptible.

Have other users noticed problems with last and lastb recently? last outputs nothing but an erroneous wtmp creation date and lastb seems to show incoherent failed login data.

Please ask for any additional required information.

ATB,
Neil

[goverp]

I've a script that uses last and lastb, and yes, they both appear to be broken, at least since I deleted the old /var/tmp/wtmp and btmp files.

First problem is that it appears Arch somehow changed the group number for the "utmp" group. Some of the code appears to assume it's 20, but it got changed to 997 or 996 or something recently. (There's a forum item, or a bug report, I forget which).
Cure is to use groupmod to set it to 20.

Second, the instructions in "man last" that you can simply "touch /var/log/wtmp" don't appear to work, as that leaves the files owned by root:root, and for the security model to work, they should have group "utmp", so that requires a chgrp. It's possible only wtmp should be in grout utmp.

Last problem is that having fixed those two, last just lists one logon, and then produces stupid output:
[code]81.102.6 ts/0paul Thu Jan 1 01:00 gone - no logout
last: preallocation size exceeded[/code]
Note the stupid date. utmpdump /var/log/[i]foo[/i] similarly produces weird output. Both the wtmp and btmp files have many records, but neither last nor utmpdump appear to be able to handle them.

That preallocation size message is also crap! Google takes you to the last source code, where the date formatting routine produced a non-zero return code - though as the same message is issued in several places that's not much help. Of course, non-zero return code probably means "input I don't understand" rather than "my output too large for my pre-allocated buffer".

My guess is that some change, such as the support for 64 bit times to handle dates past 203x, has changed the layout of the [i]foo[/i]tmp files - perhaps a change in the kernel headers - that's not been reflected in the last code. But I've not had time to see if this makes sense, or is the problem.

<edit> Sorry about the non-working markup [code] and [i']. The forum post editor inserts them, but the forum doesn't respect them.</edit>