Xref: utzoo comp.bugs.2bsd:137 comp.bugs.4bsd:1284 comp.bugs.sys5:991 comp.unix.wizards:16518
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!vsi!friedl
From: friedl@vsi.COM (Stephen J. Friedl)
Newsgroups: comp.bugs.2bsd,comp.bugs.4bsd,comp.bugs.sys5,comp.unix.wizards
Subject: Re: Cuserid() is a security hole
Message-ID: <1125@vsi.COM>
Date: 31 May 89 03:38:44 GMT
References: <289@levels.sait.edu.au>
Organization: V-Systems, Inc. -- Santa Ana, CA
Lines: 26

In article <289@levels.sait.edu.au>, ccdn@levels.sait.edu.au (DAVID NEWALL) writes:
> According to the manual, cuserid(3) is supposed to "return the character
> login name of the user".  I interpret this as meaning it will return the
> login name of the invoker.  This is _not_ what cuserid() does.
>    [...]
> So people, do not, absolutely do not, rely on these functions to identify
> the user.  Use getuid() or geteuid() instead.

     Here is an alternate method that may be a little bit more
flexible (for Sys V, at least).  First get the $LOGNAME
environment variable and look up the password entry for it.  If
the uid here matches getuid (or geteuid, depending on your
application), go ahead and believe $LOGNAME.  If it doesn't
match, forgery is going on and you have to use the getuid entry.

     This technique allows multiple accounts sharing the same uid
to distinguish between them.  Presumably, the accounts only share
if fraud between them is not a big deal.

     Steve

-- 
Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 
3B2-kind-of-guy   / friedl@vsi.com  / {attmail, uunet, etc}!vsi!friedl

You can't have everything: where you would put it?