script & lock

[Kenneth Almquist]

In article <837 at auspex.UUCP>, guy at auspex.UUCP (Guy Harris) writes:
> This according to the Ultrix documentation, or the Ultrix code (either
> by inspecting the code or by probing its behavior)?  I don't have 4.2BSD
> source handy to check, but if 4.2BSD returns NULL if the user name is
> null and Ultrix doesn't, the screwup there is DEC's.

It's from the code.  The Ultrix manual page for getlogin is identical to
the 4.3 BSD manual page.  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.

What I mean by saying that Berkeley screwed up is that the code and the
documentation were in agreement (even if they were both wrong) and then
they changed the code without changing the documentation.

>> ...the name in the /etc/utmp entry is the null string.

> Which means that the S5R3 and 4.3BSD versions of "getlogin" will return
> a null pointer.  I don't have older versions handy, so I can't say that
> this behavior dates back to V7.

Well, as I recall the S5R2 code checks for the null string, but null user
strings are rare in System V utmp files because when a user logs out
in System V this fact is indicated by changing the ut_type field of the
utmp entry to DEAD_PROCESS rather than by changing the user name to the
null string.  I *think* that the check for the null string predates the
conversion to the new utmp format, in which case USG Unix at one time
(before it got the name System V and the new utmp format) actually returned
NULL if called on a terminal with no one logged on.  Does S5R3 just contain
this same check for a null string, or does in actually check whether the
user has logged out?

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.)  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, but because of the above scenario it's probably
safer to use the environment variable LOGNAME to resolve any ambiguity.
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.
				Kenneth Almquist