From: utzoo!watmath!idallen
Newsgroups: net.unix-wizards
Title: getlogin() can be fooled -- why?
Article-I.D.: watmath.2983
Posted: Fri Jul  9 18:30:50 1982
Received: Fri Jul  9 23:32:28 1982

I have discovered, to my surprise, that the C Library function
getlogin() is not a secure way of determining the name of the person
running the current process.  We need such a method here at Waterloo,
so I solicit comments on the following discussion.

Getlogin() calls ttyslot() to find the login name of the running
process.  It is possible to make getlogin() return the name of any
user currently logged on, and I don't know of an easy way to fix
this flaw.

The problem lies with the use of ttyslot().

It is claimed ("man ttyname") that ttyslot() returns the index of the
control terminal for the current process.  This is not strictly true.
Ttyslot() calls ttyname() on each of the units 0, 1, and 2 (in that
order) until it finds one which is attached to a terminal.  But --
there is no guarantee that the first terminal it finds is the real
controlling terminal.  Indeed, it could be *any* terminal controlled by
any currently active user!

You can fool getlogin() into thinking you are someone else by
redirecting I/O units to or from the other user's terminal.  For nice,
friendly systems, this is not a problem.  For accounting purposes,
however, it is not acceptable, since this makes it possible to charge
resources or submit requests as if you were that other user.

To find the name of the current user, documentation tells me to use
getlogin() first, and, if that fails, use getpwent().  Since many,
many, programs do this, I am amazed to discover that getlogin() can be
fooled.

Apparently there is *no* secure way of determining the controlling
terminal of the current process (the terminal from which the current
process was submitted).  Am I right?  As it stands, getlogin() cannot
be used because it can be fooled.  I don't see any use for getlogin()
because of this flaw, and I am amazed that any program uses it.

Why does ttyslot() use such an ad-hoc method of determining the
controlling terminal?  Running down the I/O units and taking the first
one that happens to be a terminal seems wrong.

Comments on my view of this problem, and suggested fixes, are welcome.

	-IAN!    U of Waterloo    (decvax!watmath!idallen)