Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ucsfcgl.UUCP Path: utzoo!linus!decvax!ucbvax!ucsfcgl!gregc From: gregc@ucsfcgl.UUCP (Greg Couch%CGL) Newsgroups: net.unix-wizards Subject: Re: Problem running 4.2 rdump from a workstation Message-ID: <386@ucsfcgl.UUCP> Date: Mon, 12-Nov-84 15:28:41 EST Article-I.D.: ucsfcgl.386 Posted: Mon Nov 12 15:28:41 1984 Date-Received: Thu, 15-Nov-84 00:41:44 EST References: <665@erix.UUCP> Organization: UCSF Computer Center Lines: 47 > 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);