Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site osu-eddie.UUCP
Path: utzoo!watmath!clyde!cbosgd!osu-eddie!karl
From: karl@osu-eddie.UUCP (Karl Kleinpaste)
Newsgroups: net.unix-wizards
Subject: Re: Re: deceptive mail and /bin/login
Message-ID: <116@osu-eddie.UUCP>
Date: Wed, 21-Nov-84 08:21:12 EST
Article-I.D.: osu-eddi.116
Posted: Wed Nov 21 08:21:12 1984
Date-Received: Thu, 22-Nov-84 07:33:42 EST
References: <5857@brl-tgr.ARPA> <510@watcgl.UUCP>
Organization: Society for the Advancement of Raw Weirdness
Lines: 24

----------
> How about having login check that its parent is init (i.e. parent's PID==1)?
> Then, you can still do "login newuser" from the shell, as designed, and
> everything works properly, but people who try to do the bogus
> "(login newuser)" get thrown back into their original shell without the
> wtmp ever getting changed.
----------
Correct me if I'm wrong, but I  don't think  that's going to work due to the
existence  and  use of ptys in 4.2BSD. I believe that there  are  situations
where bona fide and  legitimate  logins are  not  owned by init.  Um, rlogin
comes  to mind. We only converted to 4.2 a few weeks ago and I  haven't  had
the time to study that code  yet,  but it  seems that you're approaching the
problem  from the wrong end; many scenarios can be created  where  something
acting as a real login  session  is  not a  child  of  init. Sounds like the
problem  is that there is a need for shells to keep /etc/utmp  updated  when
they log{in,out}.

Are the shells spawned by the  window manager on Sun workstations considered
login  shells?  If  so, there's another case where the  login  is  owned  by
neither init nor rlogind.
-- 
Karl Kleinpaste @ Bell Labs, Columbus   614/860-5107    {cbosgd,ihnp4}!cbrma!kk
                @ Ohio State University 614/891-5058      cbosgd!osu-eddie!karl
                                                     karl.Ohio-State@Rand-Relay