lastlog devours universe

Andy Ross andy at plausible.org
Wed Jun 8 16:30:21 UTC 2005


Neal Becker wrote:
> If I understand correctly, tar will only handle sparse files properly
> if told to explicitly, using the --sparse flag.  Unless tar defaults
> to handling sparse intelligently without the flag, 85% of all fedora
> sysadmins are going to be really pissed.

Note that the -S/--sparse tar option is a GNUism.  The tar you get on
other systems (I checked BSD and Solaris, and the SUSv2 spec) doesn't
support it, so users coming from those systems are unlikely to know
the right voodoo to get a successful backup.  The rsync --sparse
option also seems to have had a bug tickled by this very file, so it's
hard to argue that it isn't a real-world problem:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156809

No, this isn't a system-breaking issue (except for the case of a
mildly naive user trying to backup the /var/log directory).  But it's
clearly undesirable and dumb.  Imaging the flames if windows was
discovered to have a magic file that would fill up the filesystem if
you tried to copy it to a different folder.  Why is this different?

And the file is just ancient cruft anyway.  It stores the last login
time, terminal device (or X server), and remote host for each user.  I
found a couple of non-glibc utilities that write to the file
(dhclient, useradd), but only one that actually cares to read it
(lastlog(8), which can only be run by root).  If this thing went away
tomorrow, I doubt anyone would notice.  Meaningful user login auditing
is done with other tools.  Are there any other clients for this file,
anywhere?

Note also that this is a BSD feature, and isn't part of the SUSv2
spec.  In 1979 on a VAX with 16 bit UIDs, this might have been a
worthwhile use of space (I found a 3BSD header that defined the
lastlog struct as a 12 bytes; the current glibc structure is 292 bytes
long).  On a modern 64 bit linux, it leads to the 1.2TB monstrosity
we're shouting about.  To all the "not a bug" folks: if you were
charged with deciding on a file format for storing 2 strings and a
time for each user, would this honestly be your choice?

Finally, note that its functionality is 100% duplicated by the wtmp
file and last(1) tool anyway (except for the misfeature of not storing the
user name and thus being unable to track changes in the passwd file).
One could duplicate lastlog(8) using last(1) with a few lines of perl.

Can we please stop the fanboy flamewars?  This file is a silly side
effect of the change to 32 bit UIDs, and needs to be fixed.

Andy




More information about the fedora-test-list mailing list