Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!pacbell!hoptoad!peora!rtmvax!bilver!bill
From: bill@bilver.UUCP (bill vermillion)
Newsgroups: comp.sources.d
Subject: Re: getty/login for callback
Keywords: tip getty login
Message-ID: <501@bilver.UUCP>
Date: 10 Apr 89 14:00:56 GMT
References: <180001@mechp10.UUCP> <13853@rpp386.Dallas.TX.US> <797@twwells.uucp> <28@wells.UUCP> <399@aucis.UUCP>
Reply-To: bill@bilver.UUCP (bill vermillion)
Distribution: usa
Organization: W. J. Vermillion, Winter Park, FL
Lines: 35

In article <399@aucis.UUCP] bnick@aucis.UUCP (Bill Nickless) writes:
]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.
]
]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.

On older software on the 3B2s the ulimit was set at 2048 and was
non-configureable.  The only way to get it higher was to use the login/login2
approach.  Since root is the only one who can set it higher it limited uses to
files of 1 meg (I found that out the hard way when trying to move some 25 meg
files in a few years back).

The newer system permit ulimit to be defined at a higher limit.  And putting
the ulimit in the profile makes sense (to me at least) on a system like that.

I suspect problems with the earlier systems, and the login/login2 approach
survive because of the earlier problems.


-- 
Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!bill
                      : bill@bilver.UUCP