Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!aucis!bnick
From: bnick@aucis.UUCP (Bill Nickless)
Newsgroups: comp.sources.d
Subject: Re: getty/login for callback
Summary: Maybe not a perfect idea....
Keywords: tip getty login
Message-ID: <399@aucis.UUCP>
Date: 7 Apr 89 15:05:45 GMT
References: <180001@mechp10.UUCP> <13853@rpp386.Dallas.TX.US> <797@twwells.uucp> <28@wells.UUCP>
Distribution: usa
Organization: Andrews University, Berrien Springs, MI
Lines: 51

In article <28@wells.UUCP>, edw@wells.UUCP (Ed Wells) writes:
> 
>   I have something on the 3B at the local high school that does this.
> /bin/login is now /bin/login2.  A new 'C' program called /bin/login is now
> in place to detect the username and determine if the ulimit is to be upped.
> It then 'exec's to /bin/login.  Of course, this program can be modified
> to do anything.

I forsee a possible problem with this idea:  Suppose we sit at a hypothetical
terminal on the left of the page, with an internal glance at what happens on
the right side:

Terminal Session                              Internal Workings
----------------                              -----------------
<Connection established>            1. INIT execs /bin/getty, which prints
                                       "login:" to the terminal.
login: bnick                        2. The user (me) enters my login name
                                       /bin/getty execs /bin/login, with
                                       the following parameters:
                                       argv[0]="login"
                                       argv[1]="bnick"
                                       So, /bin/login prints out "Password:"
Password: passs_word                3. Which I (in)advertantly mistype.
                                       So, /bin/login does the check, and
                                       prints out "Login incorrect\nlogin: "
Login incorrect
login: bnick                        4. So I retype the login name, and login
Password: pass_word                    does it's thing, and I type the pass-
                                       word correctly, and the thing logs 
                                       me in, and everybody's happy.

Now consider what happens in Ed Well's system.  /bin/getty exec's his
new /bin/login, which has the logname as one of the arguments.  His program
sets the ulimit appropriately FOR THAT LOGIN.  Then, the original /bin/login
(now renamed to /bin/login2) gets the same login and continues.

The problem is this:  What's to stop someone from typing something like
"root" or "news" or "sysadm" or "edw" to /bin/getty, getting the ulimit
set properly, then simply failing to log in with /bin/login2, then
logging in as myself?  /bin/login2 will ask for a new logname when the first
password check fails.

A better place to set the ulimit would be /etc/profile, which IS run before
every shell session.  For callbacks this would be just fine, but not for
setting some priveleged attribute of the terminal session.

-- 
Bill Nickless                    Andrews University Computer Science Department
...!sharkey!aucis!bnick or bnick@aucis.UUCP                  Unix Support Group

              "Help!  I'm locked up in this .signature factory!"