lamy@ai.toronto.edu (Jean-Francois Lamy) (04/13/88)
In article <8855@eddie.MIT.EDU> wisner@eddie.MIT.EDU (Bill Wisner) writes: >The standard format on System V seems to be, thanks to the vanilla passwd >file packaged with it, junk-Full Name(junk). Revolting, isn't it? Especially fun when some programs take the first half of my given name to be the "junk" (I have an hyphen in my name, like millions of people of French, German, Swedish descent -- not to forget pre-pinyin Chinese spellings). The fun part is that at least it shortens my name to Francois Lamy, which is the correct familiar form. Better than all the humans who insist on calling me John... Jean-Francois Lamy AI Group, Department of Computer Science lamy@ai.toronto.edu University of Toronto, Canada M5S 1A4 uunet!ai.toronto.edu!lamy
psc@lznv.ATT.COM (Paul S. R. Chisholm) (04/14/88)
< If you lined all the news readers up end-to-end, they'd be easier to shoot. >
The fifth colon separated field in /etc/passwd is officially known as
the GCOS field, because it was "used only when communicating with that
system, and in other installations can contain any desired
information." [passwd(4)] Given the relative growth of the GCOS and
UNIX(R) operating systems, the GCOS field has become a haven for all
sorts of things, including printer bin numbers, login name of direct
supervisor, department numbers/codes, and (somewhere among the rest of
this trash) a legible name for the user. It's this last I'm interested
in.
My group is looking for a standard way that mail(1) can get a user's
name from a password file entry. The proposed solution is to take
everything up to (but not including) the first left or right
parenthesis (or, of course, up the the terminating colon). Some
members of another group in the area have suggested ending before the
first parenthesis, but stripping off everything before (and including)
a hyphen. Either way, a system-wide parameter would control whether
mail would use this legible name.
How would either of these algorithms work for *your* password file?
Would they lose part of your name? Would they still include junk? If
one or the other was implemented, would you face a major effort to
bring your password file into line?
Since these (optional) changes are intended for the UNIX System V
Release 4 implementation of /bin/mail, I'd greatly appreciate your
comments.
-Paul S. R. Chisholm, {ihnp4,cbosgd,allegra,rutgers}!mtune!lznv!psc
AT&T Mail !psrchisholm, Internet psc@lznv.att.com
I'm not speaking for my employer, I'm just speaking my mind.wisner@eddie.MIT.EDU (Bill Wisner) (04/16/88)
The most commonly used format used in the GCOS field is Full Name,junk,junk. This is mainly used on BSD systems but I know of some SysV sites that have picked up the habit. The standard format on System V seems to be, thanks to the vanilla passwd file packaged with it, junk-Full Name(junk). Revolting, isn't it? It's probably best to check for both. And, of course, allow for a field containing nothing but Full Name. ..b
diamant@hpfclp.HP.COM (John Diamant) (04/17/88)
> My group is looking for a standard way that mail(1) can get a user's > name from a password file entry. The proposed solution is to take > everything up to (but not including) the first left or right > parenthesis (or, of course, up the the terminating colon). Some > members of another group in the area have suggested ending before the > first parenthesis, but stripping off everything before (and including) > a hyphen. Either way, a system-wide parameter would control whether > mail would use this legible name. Well, it sounds like what you need here is a standard. As it turns out, there already is a defacto standard for interpretation of the GECOS field on Unix. It's defined by finger (a BSD-ism similar to who). It uses commas as separators. The fields it knows about are: user name, office location, office phone, home phone It ignores any fields after the ones it knows about and sendmail already knows how to pull your user name out of the first field (up to the first comma). So please use this standard and don't invent a new one. By the way, if there are no commas, the entire GECOS field is assumed to be the user name. > How would either of these algorithms work for *your* password file? No, sir, they would not. The problem is that I already run finger and sendmail and I have to use that format, so if you come up with an incompatible format, it would be impossible to satisfy both sets of programs at once. > Would they lose part of your name? No. > Would they still include junk? Yes. > If one or the other was implemented, would you face a major effort to > bring your password file into line? No, but then I couldn't bring it into conformance because it would break my other programs. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
wcs@skep2.ATT.COM (Bill.Stewart.<ho95c>) (04/25/88)
In article <1361@lznv.ATT.COM> psc@lznv.ATT.COM (Paul S. R. Chisholm) writes:
:My group is looking for a standard way that mail(1) can get a user's
:name from a password file entry. The proposed solution is to take
:everything up to (but not including) the first left or right
:parenthesis (or, of course, up the the terminating colon). Some
:members of another group in the area have suggested ending before the
:first parenthesis, but stripping off everything before (and including)
:a hyphen. Either way, a system-wide parameter would control whether
:mail would use this legible name.
Horror stories about why this is dangerous:
The Div 452 passwd command checks whether your new password
resembles your login name, and also checks whether it resembles your
RJE job account number, by looking for the first (, then searching
for the next ). When I used it on my lab machine, which didn't have
RJE fields, it dumped core. Of course it was doing this at login
time when your passwrd expired, so you couldn't get on. Why did it
dump core? Because the authors *knew* there would be parentheses
there, not more than 6 characters apart. Since the ( wasn't there,
it walked off through memory looking for one, and started copying
characters into a field until it found a ) somewhere, or until it
memory-faulted the read or trashed something on the write.
AT&T people named "Firstname M Lastname-Hyphenated" used to get
their names truncated to "Hyphenated" in netnews signatures.
Berkeley UNIX provides a "change full name" utility to allow you to
edit your gcos field. Even if you can beat the obvious security
risks, users will still generate troublesome names.
Locally-written "finger" and accounting programs will use formats
designed to confuse you.
Maybe my name really *is*
temp-clerk-3 (see Mike for details)
:Since these (optional) changes are intended for the UNIX System V
:Release 4 implementation of /bin/mail, I'd greatly appreciate your
:comments.
Be extremely careful, or take the conservative approach (whole field).
Be excessively careful about bounds-checking.
You will always get junk some places. Tolerate it.
Do replace occurences of common mailer punctuation such as
()<> and maybe @!. with safer characters. Don't just
use spaces, since they may break things.
Our password files gecos-fields used to have random items in random
order, depending on who installed the user and why. When we decided to
consolidate several systems, we wrote an add-user script to add new
users, and I wrote a pattern-matching script to try to clean up
existing entries. (It was about 90% accurate, which is enough to let
you finish by hand.) The result has evolved into the silliness in my
address line above, with department number, phone, room, several kinds
of accounting, home machine, no-spaces-so-antique-accounting-doesn't-break,
and incidentally my name. If your software can extract the real
information out of *that* by more than pure chance, I'll be impressed.
Or I'll need to update the accounting package again.
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# skep2 is a local machine I'm trying to turn into a server. Please send
# mail to ho95c or ho95e instead. Thanks.paht@ihlpg.ATT.COM (Harrington_Taber) (04/25/88)
In article <76@skep2.ATT.COM> wcs@ho95e.UUCP (46323-Bill.Stewart.<ho95c>,2G218,x0705,(HOB076)1305) writes: >In article <1361@lznv.ATT.COM> psc@lznv.ATT.COM (Paul S. R. Chisholm) writes: >:My group is looking for a standard way that mail(1) can get a user's >:name from a password file entry. What about the exptool called 'whois'? As you can see by the header I have a hyphenated name and the tool appears to do the job correctly. I am not sure who the provider is for this tool, but I think that they could help you with your problem Paul Harrington-Taber, Network Systems at Bell Labs Indian Hill Main (312)-979-5081, IH 1D-409, ihlpg!paht
douglas@dcc1.UUCP (Douglas B. Jones) (04/28/88)
In article <1361@lznv.ATT.COM> psc@lznv.ATT.COM (Paul S. R. Chisholm) writes: >Some >members of another group in the area have suggested ending before the >first parenthesis, but stripping off everything before (and including) >a hyphen. Either way, a system-wide parameter would control whether >mail would use this legible name. >Since these (optional) changes are intended for the UNIX System V >Release 4 implementation of /bin/mail, I'd greatly appreciate your >comments. >-Paul S. R. Chisholm, {ihnp4,cbosgd,allegra,rutgers}!mtune!lznv!psc >AT&T Mail !psrchisholm, Internet psc@lznv.att.com >I'm not speaking for my employer, I'm just speaking my mind. I would not use a hyphen (-) as a delimiter. Some names have hyphens in them. Possibly some foreign names. In the case of a female who gets married; she might take her husbands' last name and her last name, combine them with a hyphen between the two. I HAVE seen this! Douglas -- Douglas B. Jones seismo!gatech!dcc1!douglas DeKalb College douglas@dcc1 555 N. Indian Creek Drive Clarkston, Ga. 30021 / (404) 299-4233
ecc@ihuxy.ATT.COM (Claeys) (04/29/88)
If you're running on an R&D UNIX system machine (formerly called 452 UNIX), you can use the getpwcom(3X) routine and use the c_name field to access the GCOS field. Most of the larger R&D comp centers have some tools to help add, modify, and delete logins, and those tools usually use getpwcom(3X) and putpwcom() to access the GCOS field. The bug in the passwd command that would dump core when the GCOS field wasn't in the format specified in getpwcom(3X) has been fixed in R&D UNIX; you'll eventually see it on your machine. Eric C