Numeric usernames
Beardy
> One of my clients has suggested using 8 digit staff numbers as
> usernames on Unix systems. I have already pointed out that this breaks
> the standard SA tools on Solaris (and every other Unix/Linux I've tried
> it on);
>
> charon{root}128: useradd 01234567
> UX: useradd: 01234567 name first character should be alphabetic.
> UX: useradd: 01234567 name should have at least one lower case character.
>
> The suggestion has now been made back to me that we just ignore the
> tools and create the accounts by editing passwd files directly. Now
> that I've calmed down enough to type rationally, can anyone suggest
> reasons why this doesn't work?
>
> (I already know that it causes problems with chown. Where else is it
> going to go bang...)
>
Dunno about going bang (yes, chown is amusing in that you have to have
usernames and uid's identical, or it becomes very strange), but if you
are going to put usernames in the comment field in /etc (so that you,
the sysadmin) can actually relate a home directory to a person, then
everyone has access to everyone's staff number. Some people may not like
this.
Try saying "no-one else in the world does this."... You probably have
already :-(
Dunno...
Logan Shaw
> One of my clients has suggested using 8 digit staff numbers as
> usernames on Unix systems. I have already pointed out that this breaks
> the standard SA tools on Solaris (and every other Unix/Linux I've tried
> it on);
If the facts, good engineering, and best practices fail to dissuade
him, you might consider mapping the first digit (assuming they're
zero-padded to 8 digits) to a letter, like this:
( 0 .. 9 ) -> ( a .. j )
So, for example, 08675309 becomes a8675309, and 43218765 becomes
d3218765.
By the way, if you adopt this scheme and people wind up using
their Unix accounts to send and receive e-mail, aren't you going
to have to pick more palatable names anyway? Does your boss
know you can easily store employee numbers in the GECOS field?
One other thing I can think of possibly failing is
the /etc/mail/aliases file. Whatever appears after a colon
in an alias is parsed somewhat magically, in that sendmail
(or other compatible MTA[1]) looks at the string and makes
a determination whether the string is a command, a filename,
a local username, a remote address, etc. I don't know
precisely how it goes about this, but it does regard anything
that begins with the "|" character to be a command,
anything that begins with the "/" character to be a
filename, etc. So wanna take guesses on how it tells whether
something is a local username?
Likewise, /etc/mail/sendmail.cf might do something similar
in some cases. Or maybe not, who knows? (That's sort of
the point, of course -- who does know, and should your
organization be either spending lots of effot to find out
or dealing with unexpected consequences?)
And of course, it's usually considered necessary to have a
working sendmail (or whatever) even if you really use
the Unix machine for reading your mail. This is because,
of course, things like "at" and "cron" send you mail to
notify you of things.
Another file whose grammar must (or probably does) use a
similar approach to /etc/mail/aliases is syslog.conf.
You can send log messages to users, to files, to the syslog
daemon on another server, etc. Once again, if the file
begins with "/", it's regarded as a file. If it begins
with an "@", then it's regarded as the name of a remote
host. If it's a "*", then it means all users. And how
do they detect when it's a username? Maybe it works by
the process of elimination and everything that doesn't
begin with "@", "*", or "/" is a username. Or maybe
not -- maybe it only matches legal first characters
for a username. And, sure, maybe the syslog.conf works
now, but what if you replace syslog with a different
version?
- Logan
[1] But do they REALLY behave the same?
Tony Walton
> One of my clients has suggested using 8 digit staff numbers as
> usernames on Unix systems. I have already pointed out that this
> breaks the standard SA tools on Solaris (and every other Unix/Linux
> I've tried it on);
>
> character should be alphabetic. UX: useradd: 01234567 name should
> have at least one lower case character.
>
> The suggestion has now been made back to me that we just ignore the
> tools and create the accounts by editing passwd files directly. Now
> that I've calmed down enough to type rationally, can anyone suggest
> reasons why this doesn't work?
>
> (I already know that it causes problems with chown. Where else is it
> going to go bang...)
>
It shouldn't actually break anything as far as the OS is concerned. The
OS doesn't care about the content of a username - a username is a string
of characters and "string of characters" applies as much to"95095701" as
it does to "azertyuio". Some commands, however, will be confused - you
mention chown (which in fact will assume "98765" is a userNAME rather
than a userID if "98765" does exist as a userNAME) but without a
reasonably detailed read of all the manual pages (or preferably the
sourec code) I wouldn't care to guarantee that nothing at all assumes
that "all numbers" is a userID. This does double for custom-written code
such as scripts, of course.
What this just about *is* guaranteed to break is your system
administrators. They're almost bound to be severely confused by seeing
ls -l listings that look like
ls -l freds
-rw-r--r-- 1 98765431 other 0 Jan 29 14:02 freds
but
ls -ln freds
-rw-r--r-- 1 12345 other 0 Jan 29 14:02 freds
I'm sure you'll take time and effort to teach the current system admins
about this (frankly odd) way that things have been set up, but are you
willing to keep answring the same questions from this client in six
months time, when they've taken on new staff?
Why not simply prepend some initials to the staff number, like some
corporations I could name?
ls -ld ~
drwxr-xr-x 123 tw25440 other 14848 Jan 28 16:20 /home/tw25440
Of course, as Beardy says elsewhere in this thread, there might be a
downside to giving everyone on the system access to someone else's staff
number... That's another story.
--
Tony
Beardy
> Tony Walton <tony.walton@s_u_n.com> writes:
>
>>Huge wrote:
>>
>>>One of my clients has suggested using 8 digit staff numbers as
>
>
>
>
>>sourec code) I wouldn't care to guarantee that nothing at all assumes
>>that "all numbers" is a userID.
>
>
> create such accounts, and that even if we don't know what it is, we
> shouldn't go against it.
>
>
>>This does double for custom-written code
>>such as scripts, of course.
>
>
>
>
>>What this just about *is* guaranteed to break is your system
>>administrators.
>
>
>
>
> [22 lines snipped]
>
>
>>Of course, as Beardy says elsewhere in this thread, there might be a
>>downside to giving everyone on the system access to someone else's staff
>>number... That's another story.
>
>
>
> The only conclusion I've reached so far is that PHBs are alive and
> well.
>
>
"PHB"? "Pointy haired boss" (Dilbert)? Probably not "Player's HandBook"
(Advanced Dungeons and Dragons)... Your definition?
Rich Teer
> One of my clients has suggested using 8 digit staff numbers as
> usernames on Unix systems. I have already pointed out that this breaks
> the standard SA tools on Solaris (and every other Unix/Linux I've tried
> it on);
>
> charon{root}128: useradd 01234567
> UX: useradd: 01234567 name first character should be alphabetic.
> UX: useradd: 01234567 name should have at least one lower case character.
>
> The suggestion has now been made back to me that we just ignore the
> tools and create the accounts by editing passwd files directly. Now
> that I've calmed down enough to type rationally, can anyone suggest
> reasons why this doesn't work?
Hmm. IMHO, a client so clueless is bound to be more trouble
than they're worth...
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
cbi...@somewhereelse.nucleus.com
> One of my clients has suggested using 8 digit staff numbers as
> usernames on Unix systems. I have already pointed out that this breaks
> the standard SA tools on Solaris (and every other Unix/Linux I've tried
> it on);
There's a simple, but not necessarily easy solution to this.
Say "no."
Flat out REFUSE to do this. Tell the client that you won't do it,
for whatever reason you want. (If it breaks the SA tools, then
clearly it's not an acceptable standard. If chown gets confused,
then it's clearly a dangerous standard.) If they continue to push
for it, then the question comes up of why they've hired you at all,
if they don't trust your advice.
As an extreme, you can always walk away from a client, depending on
the circumstances. (i.e. bills to pay, the odds of improving or
diminishing your reputation, etc.)
Colin
Kjetil Torgrim Homme
>
> [quote elided due to X-No-Archive: yes]
I'd just prepend a "u" or something. all numeric user names are going
to cause much more problems than they're worth, just say "no".
--
Kjetil T.
Logan Shaw
I was going to suggest that, but to 9-char usernames that
start with a letter cause more problems than 8-char usernames that
start with a digit, or is it the other way around?
(The original poster said the employee numbers are 8-digit.)
- Logan
Casper H.S. Dik
>Kjetil Torgrim Homme wrote:
>> [Huge]:
>>
>>> [quote elided due to X-No-Archive: yes]
>> I'd just prepend a "u" or something. all numeric user names are going
>> to cause much more problems than they're worth, just say "no".
>I was going to suggest that, but to 9-char usernames that
>start with a letter cause more problems than 8-char usernames that
>start with a digit, or is it the other way around?
There are a few parts of Solaris which have trouble with longer
usernames, but the troubles are fairly minor.
There are also parts which will first call atoi and then getpwnam()
(parts of RBAC).
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Logan Shaw
> There are a few parts of Solaris which have trouble with longer
> usernames, but the troubles are fairly minor.
That's nice to hear. But what about third-party software that
just KNOWS that a username isn't longer than 8 bytes? It might
do something like this:
struct auth_record
{
char username[9];
char haswizardaccess;
};
/* ... */
struct passwd *passwdptr = getpwuid (theiruid);
if (passwdptr == NULL) { return false; }
authrec->haswizardaccess = 0;
strcpy (authrec->username, passwdptr->pw_name);
Now, suddenly, with a 10-char username, haswizardaccess is true
instead of false. (Or false instead of true, if you have a
9-char username and you initialize haswizardaccess to 1.)
Granted, this is bad code, but there is lots of stuff out there
that has buffer overflows...
- Logan
Doug McIntyre
>Casper H.S. Dik wrote:
>> There are a few parts of Solaris which have trouble with longer
>> usernames, but the troubles are fairly minor.
>That's nice to hear. But what about third-party software that
>just KNOWS that a username isn't longer than 8 bytes? It might
>do something like this:
We've run longer usernames for years and have very little problems
with them. Most of issues revolve mostly around display of usernames
(ie. users get confused when there might be say usernames with the
same 8 characters in the front, with some change past that between two
different users. Alot of utils only display 8 chars of the username,
so they wonder which user it is, and usually guess wrong and complain).
I can't think of any program that actually did something wrong because
a user had a longer than 8 char username..
--
Doug McIntyre mer...@visi.com
Network Engineer/Jack of All Trades
Vector Internet Services, Inc.