Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: script & lock
Keywords: getlogin(3)
Message-ID: <844@auspex.UUCP>
Date: 14 Jan 89 05:41:25 GMT
References: <17972@adm.BRL.MIL> <596@cf-cm.UUCP> <15399@mimsy.UUCP> <837@auspex.UUCP> <6937@june.cs.washington.edu>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 73

>The getlogin code for Dynix (which claims 4.2 BSD compatibility) is
>identical to the Ultrix code, so I assume that the code in both systems
>is the 4.2 BSD code.

If that is the case, I'm slightly surprised; unfortunately, I don't have
4.2BSD code handy to check against.

>I *think* that the check for the null string predates the conversion to
>the new utmp format,

In which case it may well date back to V7; if so, I'd be even more
surprised if the check were missing from 4.2.

>Does S5R3 just contain this same check for a null string, or does
>in actually check whether the user has logged out?

S5R3's "getlogin" checks whether "ubuf.ut_user[0]" is '\0', and if so
returns NULL.  It does not check the "ut_type" field of the entry. 
"ttyslot" accepts either INIT_PROCESS, LOGIN_PROCESS, USER_PROCESS, or
DEAD_PROCESS.  Since DEAD_PROCESS or INIT_PROCESS will show up if
somebody's logged out and nobody's logged in subsequently, and since
"init" stuffs the name of the *program* it ran into "ut_user" when it
sets the type to INIT_PROCESS, this seems to indicate that if there's
nobody logged in, "getlogin" will neither return NULL *nor* a null
string - it'll return the name of the person who logged in last, or
something like "getty"!  (It obviously won't return a null string, since
it checks for that and returns NULL.)

Perhaps there's a reason for this behavior, but given what "getlogin" is
supposed to do I don't see why it doesn't accept only USER_PROCESS and
maybe LOGIN_PROCESS in the "utmp" slot.

>In any case, getlogin is inherently risky under System V since a user
>can start up a background process, log out, and allow someone else to
>log in.  At this point getlogin will return the login name of the new
>user, not the name of user that started the background process.  (The
>vhangup call is supposed to prevent this scenario from occurring under
>Berkeley UNIX.)

It prevents it because it invalidates any file descriptors the program
has that refer to that tty.  Of course, if you start up a background
process and log out, it's not supposed to have any file descriptors for
the tty - otherwise, it can do amusing and possibly unpleasant things to
the owner of the current session - and "nohup ... &" will ensure that is
the case.  If you don't do "nohup", the SIGHUP sent to your tty when
your login shell exits should blow away the process in question.

(This brings up the general problem of disconnecting remnant processes
of a session from the session's tty, which is, I think, being discussed
in another thread here.)

Of course, none of the above is guaranteed to happen, so it's
conceivable that a program could have "getlogin" not fail when run in
the background and left behind after the session is terminated.

>If a program really wants to find out who invoked it, it should search
>the password file for the user's id.  The name returned by getlogin can
>be used to resolve the ambiguity if more than one user has the same
>user id,

>Of course a malicious user can reset LOGNAME; if you have malicious users
>that you must distinguish between, the only safe approach is to give them
>separate user ids.

If they're malicious, I'd give them separate user IDs just to keep them
from being malicious to each other, unless you know they wouldn't do
that....

I seem to remember reading somewhere in a V8 manual that V8 had what, if
I remember, was an old PWB idea (dating back to V6, when you had 1-byte
user IDs and users *had* to share them) of having the login name stored
securely in the U area, with a system call to get and set it.  Is this
the case?