Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site erix.UUCP
Path: utzoo!linus!decvax!genrad!mit-eddie!godot!harvard!seismo!mcvax!enea!erix!per
From: per@erix.UUCP (Per Hedeland)
Newsgroups: net.unix-wizards
Subject: Problem running 4.2 rdump from a workstation
Message-ID: <665@erix.UUCP>
Date: Sat, 10-Nov-84 01:01:52 EST
Article-I.D.: erix.665
Posted: Sat Nov 10 01:01:52 1984
Date-Received: Sun, 11-Nov-84 19:59:21 EST
Reply-To: per@erix.UUCP (Per Hedeland)
Organization: L M Ericsson, Stockholm, Sweden
Lines: 19

Sorry if this is common knowledge, but I haven't seen it discussed before...

If you have a network of workstaions and a VAX, you probably don't want to 
generally grant superuser priviliges on the VAX to everyone running as such on
a workstation, and accordingly the validation routines skip /etc/hosts.equiv 
when you try to become superuser on the remote host. The problem with such a 
setup is that when you use e.g. 'rdump' from the workstation, you'll normally 
have to be superuser, meaning that you can't access the VAX at all!

One workaround would be to have a userid with another name than "root", which
would be superuser on the workstation but not on the VAX. However, 'rdump' has
"root" hardcoded, and doesn't care what the current userid is! Is there a
reason for this? Are there any other (better?) solutions to this problem?

I suppose what one would really want is for "root" on a host listed in
/etc/hosts.equiv but not in /.rhosts to be allowed to do rdump (rsh, rcp...)
with a generic "other" userid, i.e. with no particular access rights...

Per Hedeland   {decvax,philabs,seismo}!mcvax!enea!erix!per  or  per@erix.UUCP