Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: Cuserid sometimes gives incorrect info!
Message-ID: <19124@rpp386.cactus.org>
Date: 26 Mar 91 06:16:08 GMT
References: <1991Mar19.005559.6424@ccu1.aukuni.ac.nz> <16040.27eab416@levels.sait.edu.au>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 25
X-Clever-Slogan: Recycle or Die.

In article <16040.27eab416@levels.sait.edu.au> xtdn@levels.sait.edu.au writes:
>russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes:
>> It is a nasty security loop hole for the unwary. We had a setuid program
>> which used cuserid to check identity of the person running the program
>
>Using cuserid to verify the identity of the caller is a security hole
>that just begs to be exploited.  Used in conjunction with getuid, it
>can be useful.

The best way to determine user ID is to get the login name from the
utmp file and look it up in the password file.  If the uid from the
password file matches the current user ID, assume you got the right
name.  Otherwise, take the current user ID and look it up in the
password file.  Use the name that you get back.  This can fail in
different ways, such as if there are non-unique user ID's.

This is far from perfect and points to the usefulness of the "login
id" or "privileged environment".  Both of these concepts can be found
in various systems, such as those provided by SecureWare and Locus
Computing.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) |  Domain: jfh@rpp386.cactus.org
"I want to be Robin to Bush's Batman."
                -- Vice President Dan Quayle