[OpenAFS] overide 8 char userids?

[Marcus Watts]

Corey Kovacs <ckovacs@DEPAUW.EDU> writes:
> uss: * User field in add cmd too long (max is 8 chars; truncated value is
> 'jgeringe')
> LINE 7 FAIL add jgeringer:Jason Geringer:<initial password>
> here::helios:a::1010

That message comes from uss/uss.c, comparing against the length of uss_UserLen,
which is set in uss/uss_common.h,
	#define uss_UserLen                  8

One of the wonderful advantages of open source software is that these
kinds of questions can be answered by just "Using the Source" - no need
to ask in a mailing list "if AFS has a limit"...(IMHO).

The *why*, on the other hand, cannot be answered in the source, and
is a good question for a mailing list like this.

While AFS is doing limit checking here, it's not (just) an AFS limit;
it's also a standard generic Unix limit.  Indeed, it's not really an
AFS limit at all, pts IDs, kerberos instances, etc., volume names, etc.,
can all be well over 8 characters and also include non-alphanumeric
characters characters, so you won't find the the actual reason there
at all.

The real reason is in fact straight Unix - since at least version 6,
the "8 characters max" limit has been in effect, and this shows up
in many separate bits of software, not in any one neat easily defined piece.
In fact, different Unix systems may have different problems, so
just because you've "solved" it on one kind of system, doesn't mean
you won't run into problems elsewhere on another kind of system.
For instance,:

On most (if not all) Unix systems, the field ut_user in "struct utmp"
(commonly defined in <utmp.h>) is set to 8 characters.  The "rwhod" and
"rusersd" protocols have 8 characters baked into the wire protocol
(used by programs such as ruptime, rwho, rusers).  NIS has an 8
character limit, but of course if you have AFS and kerberos you should
not be using NIS.  Software that does any sort of name caching on
entries from /etc/passwd is to have 8 wired in as the length of names
it saves (it's much cheaper to always allocate 8 bytes than to assume
the overhead of variable sized fields and the extra overhead and
inevitable fragmentation that can result).  In solaris, programs that
might do loginid caching include nscd, ls, acctcom, lastcomm, etc.
None or all of these programs may in fact have problems; since solaris
isn't open source this would require research.

Tar and cpio (may) know about loginids as opposed to uid; if so,
there's an 8 character limit there.  Originally, both tar & cpio used
numeric UIDs, but generally ascii names are more portable, and are used
by newer versions of tar.

In OpenBSD (at least as of 2.4, which is now ancient history), the
/etc/security script will gripe if it finds loginids > 8 characters.

So, exceeding this limit may or may not break anything you consider
important.  If you have a small and well controlled environment,
running most open source machines, and your users will not need the use
of tar, rwho, etc., you can probably afford to "fix" the 8 character
limit.  If you plan to use tar, rwho, want to easily compile open
source for programs "off the net" without extensive coder reviews, or
have machines running proprietary OSes (while it's possible to get and
change solaris source for "research" purposes, you can't use it even
for "internal deployment"), or etc., then you probably won't want to
exceed 8 characters.

				-Marcus Watts
				UM ITCS Umich Systems Group