Cuserid() is a security hole

[Guy Harris]

>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.

Which manual is "the manual"?  The S5R3 manual page says it returns "a
character-string representation of the login name that the user of the
current process is logged in under", which makes it not surprising that,
as you note:

>In fact, cuserid() returns the login name of the person who is logged in
>on the terminal pointed to by stdin, stdout or stderr.

>Oh, and the same applies for getlogin().

In fact, "cuserid" in AT&T's implementation just tries to do a
"getlogin" first and, if that fails, uses "getpwuid(getuid())".  I
assume any Berkeley implementations do the same....

>So people, do not, absolutely do not, rely on these functions to identify
>the user.  Use getuid() or geteuid() instead.

Yup.  In most versions of UNIX, there is *no* guaranteed way to get the
login name for the current session, since doing so basically involves 1)
getting the tty name for the current session and 2) finding the "utmp"
entry for that session, and 1) can only be done if you have a handle on
that tty, and as you note there's no way of reliably getting such a
handle (no, "/dev/tty" doesn't do so - an "fstat" on it will, in all
UNIXes with which I'm familiar, report the major and minor device number
of "/dev/tty", and thus doesn't give you enough information to find the
device in "/dev" to which it refers).

I think some versions may actually stash the login name in the U area
with a privileged call, and provide a call to fetch it.  (I think
PWB/UNIX 1.0 did this; I seem to remember something in the V9 manual
that indicated that there might be such a call there.)

It is worth noting that, in some cases, you may *want* the answer that
"getpwuid(getuid())" or "getpwuid(geteuid())" gives you, and not the
answer that even an "unbreakable" "getlogin()" would give you....