Subject: Re: misc/2668: login-names >8 chars make no fun
To: matthew green <firstname.lastname@example.org>
From: Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>
Date: 08/15/1996 21:49:40
> Either you change the binary format of utmp and wtmp, or you don't.
> If you don't, you aren't recording all of the login name.
> If you do, you break binary compatibility.
> except if you take the idea that SVR4 used (creating another file,
> with much larger username/hostname/etc, but still fixed size
> entries, and then having the routines to update this file also
> maintain the utmp/wtmp files) and learn from their mistakes and
> come up with a *real* solution, that just happens to also maintain
> backwards compatibility.
As in: have, say, another file which contains user names, and have
utmp/wtmp point to entries in the second file?
It seems that that's slow, unnecessarily complicated, and unless done
carefully can be prone to not keeping accurate track of the
Re: the latter: For instance, say on day 1 i have user bob with uid
1000. bob logs in, logs out. day 2: i delete bob's account. day 3:
i add a new account, joe, with UID 1000. either the second (database)
file is ever-increasing in size (and no entries are re-used), or it's
indexed by a bogus index (e.g. the UID), which can yeild the wrong
results in the case given above. Given that these files are e.g. used
for system accounting, that's a bad situation to be in. Right now,
it's not a problem, since the user name is stored... (yeah, if you
have a new user with the same name as an old, removed, user, you'll
have a problem, but you could either way.)
> you could also "break" binary compatibility but retain the ability
> to read the old format with updated tools that do both.
That's relatively difficult, since the files and/or records in
question have no magic number by which you can determine their
versions. Sure, you could use a heuristic, but it's quite likely that
it wouldn't always work.