William LeFebvre <phil@RICE.ARPA> (11/17/84)
> Make /bin/login mode 500 owned by root and it will fail on exec, > usually causing /etc/init to fork another copy of itself and the > new user to thus get a fresh copy of /bin/login for normal login, Of course, if you are dialed up or are connected through a switch on a line that has the TIOCHPCL bit set, the line gets dropped before init has the chance to start a new getty (getty execs login after it gets the login name). I'm afraid I don't like that idea much. Especially since we have a ROLM switch and getty sets the TIOCHPCL bit on every switch line. Being able to just say "login user" rather than struggling with the switch is a big win. William LeFebvre Department of Computer Science Rice University <phil@Rice.arpa>
dmmartindale@watcgl.UUCP (Dave Martindale) (11/20/84)
> > Make /bin/login mode 500 owned by root and it will fail on exec, > > usually causing /etc/init to fork another copy of itself and the > > new user to thus get a fresh copy of /bin/login for normal login, > > Of course, if you are dialed up or are connected through a switch on a > line that has the TIOCHPCL bit set, the line gets dropped before init > has the chance to start a new getty (getty execs login after it gets > the login name). I'm afraid I don't like that idea much. > William LeFebvre 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.
karl@osu-eddie.UUCP (Karl Kleinpaste) (11/21/84)
---------- > 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