Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site turing.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!mcvax!turing!aeb
From: aeb@turing.UUCP
Newsgroups: net.unix-wizards
Subject: Re: deceptive mail
Message-ID: <225@turing.UUCP>
Date: Sat, 17-Nov-84 12:47:21 EST
Article-I.D.: turing.225
Posted: Sat Nov 17 12:47:21 1984
Date-Received: Sun, 18-Nov-84 22:37:44 EST
References: <331@uvm-cs.UUCP> <45@uwvax.UUCP>, <221@turing.UUCP> <4632@utzoo.UUCP>
Organization: CWI, Amsterdam
Lines: 27
Apparently-To: rnews@mcvax.LOCAL

>> It is even worse: if you are working at a terminal, somebody comes along
>> and in order to show you something logs in recursively: (login x)
>> then after his login process has finished your identity will be reported
>> as x by programs like who and routines like getlogin().

> This should not be a staggering surprise; the login operation is not
> recursive, and trying to use it that way is obviously a disaster in the
> making.  The correct approach to this particular problem is to fix login
> to recognize, and reject, attempts at recursive logins.
-- 
                                Henry Spencer @ U of Toronto Zoology
                                {allegra,ihnp4,linus,decvax}!utzoo!henry

Well, perhaps. I do not see the possibility of a recursive login as
something that is broken and should be fixed, in fact I use it almost daily.

My only point was to warn you that the value returned by getlogin() is
not always reliable.

There is a difference between  (login x)  and  su x : in the first case
you get into the home directory of x, his .profile or .login is executed etc.;
in the second case your working directory remains unchanged and your
environment is unchanged except for SHELL and HOME. I need the former kind
of behaviour, but can well imagine that other people prefer the latter.

-- 
      Andries Brouwer -- CWI, Amsterdam -- {philabs,decvax}!mcvax!aeb