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)