[net.unix-wizards] Problem running 4.2 rdump from a workstation

per@erix.UUCP (Per Hedeland) (11/10/84)

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

gregc@ucsfcgl.UUCP (Greg Couch%CGL) (11/12/84)

> 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

We had a similar problem here, when some of the other labs' vaxen tape drives
failed and we didn't feel like giving them root access to do dumps over the
ethernet to our tape drive.  Here's a modification to src/etc/dump/dumprmt.c
which does the right thing by allowing the rcp syntax (machine.user:file) to
be used to specify the remote tape drive.  As this isn't really a bug, but an
enhancement, this hasn't been sent to Berkeley.

					- Greg Couch
					ucbvax!ucsfcgl!gregc
					ucsfcgl!gregc@Berkeley.Arpa
-----
RCS file: RCS/dumprmt.c,v
retrieving revision 1.1
diff  -r1.1 dumprmt.c
18a18
> char	*rmtpeeruser;
22a23
> 	char	*index();
24a26,29
> 	if ((rmtpeeruser = index(host, '.')) == NULL)
> 		rmtpeeruser = "root";
> 	else
> 		*rmtpeeruser++ = '\0';
49c54
< 	rmtape = rcmd(&rmtpeer, sp->s_port, "root", "root", "/etc/rmt", 0);
---
> 	rmtape = rcmd(&rmtpeer, sp->s_port, "root", rmtpeeruser, "/etc/rmt", 0);

martin@sabre.UUCP (martin levy) (11/13/84)

<vax-busters>

The rcmd() code in rdump can be cleaned up to pass the current user and
not "root". We did this and then made /etc/rdump (and /etc/dump) setuid
with these permissions:-

	$ ls -lg /etc/*dump
	-r-xr-s---  1 root     operator    29696 Sep 27  1983 /etc/dump
	-r-xr-s---  1 root     operator    33792 Sep 27  1983 /etc/rdump

This allowed only the people in group "operator" to do dumps (while
still not giving them su privilege). As long as they have a login on
the other machine where the tape drive is and either /etc/hosts.equiv
or there own .rhosts file has the name of the workstation in it all
worked ok.
Another good thing about this method was that when the dumps were being run
on the console by the operators and they walked away from the machine, we
were not left with a console logged in as "root".

martin.

PS. /etc/rrestore does not need this code, because you should be root to
restore. well at least for complete file system.