Remote printing IRIX 3.3.1

[dale chayes]

In article <1990Dec13.150715.25685 at cunixf.cc.columbia.edu>, shenkin at cunixf.cc.columbia.edu (Peter S. Shenkin) writes:
> In article <9012110417.aa06748 at VGR.BRL.MIL> FL17 at DLRVMBS.BITNET writes:
> >
> >Remote printing works nicely via the lp account with no password.
> >However, anyone can log in as user "lp" with no password on our machines.
> >Does anyone have a method to inhibit interactive logins as user "lp"
> >while maintaining the remote printing feature ?
> 
> Wait a second -- there's something I don't understand.  Ordinarily the
> lp account is set up without a default login shell.  I guess I had assumed
> that this would inhibit interactive use of the machine by a person trying
> to login as "lp".  On a regular user account, a login shell is specified.
> So could someone tell me what does happen if someone does try to login as
> lp? Or as uucp, for that matter...

Well, I ASSUMED (makes an A.. out of U and ME), some what differently, that 
uucp and lp would have "special" login PROGRAMS, but on inspection of one 
of our 4D/20s running 3.3.1, I find that lp dosen't. The uucp account 
is "closed" with an asterix and the nuucp account does run /usr/lib/uucico 
on startup. 

To make the remote printing work, the users of this machine have removed the 
password for the lp account.  As I recall, it was the only way they could
get the remote printing to play.

Egads....

My understanding of the final field in /etc/passwd was that if you don't
specify something else, the user ends up with a Bourne shell, and that
is exactly what happens.  On further inspection, I find that you can log in
and end up in what appears to be an unrestricted Bourne shell. There is 
no .login, nor .profile, nor .cshrc in the home directory of lp.

I _suspect_ that most people who by "personal visualization" machines are
not particularly network-aware and almost certainly not aflicted with
a healthy dose of networked-system-manager's paranoia. They connect 
to networks for the benifits, but are not inclined to pay for support 
services/administration (if it is available) at least in part because 
of the nice visual admin tools that SGI provides. And, who can blame them? 

I would encourage SGI to put a little (a lot?) more effort into security 
issues before there is a public flap that gets them on the front page of
the news rags (for reasons not related to their great graphics) independent 
of the _real_ reasons.  

Yuck, 
Dale
-- 
Dale Chayes Lamont-Doherty Geological Observatory of Columbia University
Route 9W, Palisades, N.Y.  10964	dale at lamont.ldgo.columbia.edu
voice:	(914) 359-2900 extension 434	fax: (914) 359-6817