Subject: Re: bin/8428: uucpd truncates login names at 8 characters
To: None <netbsd-bugs@netbsd.org,>
From: Greg A. Woods <woods@most.weird.com>
List: netbsd-bugs
Date: 09/24/1999 19:52:40
[ On Friday, September 24, 1999 at 17:39:47 (-0400), Bill Sommerfeld wrote: ]
> Subject: Re: bin/8428: uucpd truncates login names at 8 characters 
>
> Have patience, grasshopper.  It will be fixed in the fullness of time.
> 
> One of the specific tasks I was given CVS access for way back when was
> to improve our support for long login names.

I'm eager to help where I can too...

> NetBSD is gradually evolving to better support long login names.  It
> started out extremely inconsistantly (for instance, MAXLOGIN was 12,
> but getpwnam truncated the passed-in login name to 8 characters), and
> is gradually improving.

MAXLOGNAME should have been changed immediately to 8 instead of 16 as
that's the only truly correct and most compatible change.  Increasing it
only made things worse (or at least didn't improve anything!).
 
> Fixing the "utmp" problem is not a simple matter of increasing
> UT_NAMESIZE.  Unfortunately, we can't simply increase UT_NAMESIZE; we
> really need to replace the utmp file with a new abstraction, and one
> of my many back-burner projects is to design this abstraction.  THis
> will solve multiple problems -- for instance, UT_HOSTSIZE is also too
> small.

Well, actually it is that simple, but only if you ignore backwards
binary compatability, which is supposed to be something that's a lot
easier for an operating system released in source form!  It's very sad
to see NetBSD being held back because of this.  While I do appreciate
the efforts taken to make sure that the system call interfaces are keep
compatible to at least the most recent major release, I do not see any
point to holding back on things like this.  It's really not that hard to
either provide conversion utilities for existing data or perhaps even to
make the utilities that read such data smart enough to guess at the
right data format.  This is essentially approach FreeBSD took.  Being
compatible (and I mean 100% compatible, including the fact that
MAXLOGNAME includes the NUL) with them in the interim would *not* be a
bad thing and perhaps would help convince them to follow when we come up
with an even better approach.

Now as I said I can think of at least a half-dozen workable ways to make
it possible for login records to have either less-, or even un-, limited
user-names (and for that matter hostnames too), and that's right off the
top of my head (though no doubt some of my ideas are filtered down from
various discussions on this topic over the years (i.e. ever since before
SysVr4's utmpx format was finaly chosen).  I'm willing to put enough
effort into describing the ones that I think have the most merit in more
detail if someone's going to be listening seriously.  In fact I'd have
provided code already but this feature isn't one anyone I work directly
with is in dire need of repairing and there are just way too many other
higher priority things to worry about.  However if something can raise
it on my priority list I'll certainly be working directly on a solution
at least for myself!

> In the meantime, NetBSD is certainly usable with 15-character login
> names and it would be silly to cause this functionality to regress in
> the name of a foolish sense of consistancy.

No, sorry, but that's not true.  Until/unless UT_NAMESIZE is the same
lenghth as the maximum length of a username everywhere else there's just
too much chance that login records will be screwed up.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>